yuanxiaosong

第一步： https://wiki.metacubex.one/config/inbound/tun/

第二步： https://github.com/MetaCubeX/mihomo/issues?q=macos+tun+dns

第三部：以上两步解决不了，换个软件

Error 都不提倡捕获，父类 Throwable 就更不应该处理了，所以一般都是直接处理另一个子类 Exception 。

1. 前端约等于用户输入，永远不要相信用户的输入是正确的，参见测试工程师那个段子；
2. Throwable 有两个子类，Error 和 Exception ，打开 Error 的源文件，注释上明确写了：……because most applications should not try to catch it.（翻译一下：因为大多数应用程序都不应该尝试捕获它），通常我们认为是一些硬件上或者 JVM 的问题，此时程序已经不能正常运行，事务回滚也没什么意义了。

新川路对面天天都在试车，就是不知道在运营没有

你以为它没启动，其实它是通过 service 的方式注册了，不过清理了过后向日葵就打不开了，可以尝试备份到其他文件夹，要使用向日葵的时候再还原回去。

#!/bin/bash


# 检测是否以 sudo 运行
if [ "$(id -u)" != "0" ]; then
echo "请以 sudo 执行当前脚本" 1>&2
exit 1
fi

echo 正在清理向日葵开机启动项
rm -rf /Library/LaunchAgents/com.oray.sunlogin.agent.plist
rm -rf /Library/LaunchAgents/com.oray.sunlogin.startup.plist
rm -rf /Library/LaunchDaemons/com.oray.sunlogin.helper.plist
rm -rf /Library/LaunchDaemons/com.oray.sunlogin.plist

在我看来，DDD 是一种设计，让你如何去规划这个系统，比如我们在使用微服务的时候，如何决定一个服务到底有多大，能做多少事情，它的边界在哪里，这个就可以用 DDD 来解决，比如我们在做单体服务的时候，如果有两个 service 需要业务上循环依赖，怎么去把它俩的依赖解开，确定每个 service 到底该干那些事。

DDD 是教你怎么去做做设计，不是写两个 command 、domain 就叫 DDD ，贫血/充血什么的只是具体的工具，我经常问别人，现在我们系统是基于面向过程语言编写的，它没有对象模型这种，它就不配用 DDD 了？

记得前几年看过一个大佬这样描述 DDD 的：DDD 是战略，贫血/充血是战术。

可以看一篇 infoq 的文章“DDD 和微服务之间是什么关系？”
DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。微服务架构虽好，但是他并没有给出如何对复杂系统进行分解的具体方法论，而 DDD 正好就是解决方案。
https://www.infoq.cn/article/34uhkxy98uztabz_mpui

@salmon5 我倒是觉得小公司才在后端服务里面写跨域，一般来说环境有开发/测试/预发布/生产（蓝/绿）/演示环境等，并且一个公共服务 API 会被多个产品调用，每个产品一级域名都不一样，有些产品客户还有私有化部署需求，还没考虑私有化部署需求，难道让后端把所有域名都收集好写到代码/配置里面，每次新增一个域名都改一次后端服务？众所周知，Access-Control-Allow-Origin 只能是单个域名或者*，如果一个 api 对应多个不同一级域名，代码还要
if (ALLOW_ORIGINS.cntains(requestDomain)) {
resp.addHeader("Access-Control-Allow-Origin", requestDomain);
}
这种写法，不难受么？