第一步： 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.contains(requestDomain)) {
resp.addHeader("Access-Control-Allow-Origin", requestDomain);
}
这种写法，不难受么？

@coolcoffee 正常正好相反，一个后端 API 可能对应 n 个业务线，每个业务线又有 n 个产品，鬼才知道前端用的什么域名，所以我们的操作是使用 proxy_hide_header ，不管后端服务设置什么跨域全部丢弃掉。

不使用 spring cloud/docker/k8s 管理配置
1. 使用外部 env 文件管理：
application.yml
```
spring:
config:
import: optional:file:.env[.properties]
datasource:
url: ${DATASOURCE_URL:jdbc:mysql://127.0.0.1:3306/demo?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezOne=GMT%2B8}
username: ${DATASOURCE_USERNAME:root}
password: ${DATASOURCE_PASSWORD:root}
```

.env
```
DATASOURCE_USERNAME=test
DATASOURCE_PASSWORD=test
```

优先使用 env 中的值，如果 env 中未找到对应值，则使用 yml 中的值，根据不同环境指定不同的 env 文件；

2. 启动时候通过启动参数配置
java -jar xxx.jar --spring.datasource.username=test --spring.datasource.password=test

@chaleaochexist
问题 1：在保证一个 dao 对应一个表（仅限增删改）的前提下，这个确实有很大的争论点，没有一个固定的答，它可以叫 UserDept ，也可以 DeptUser ，但是在我看来，理论上只有一个存在，除非你底层用双向链表来维护（有两个数据库表），你用 User 打头，那么你潜意识就认为这个关联关系应该由 UserManager 来维护，反之亦然。
继续问题 1：首先确定，Service 只和 Manager 打交道，类似于事件驱动，Service 会通知每一个 Manager ，我现在要删除一个部门了，真正的执行人是 Manager ，如果关联关系是 DeptManager 维护，那么它会删除 dept 表和 dept_user ，UserManager 说关联关系不是我维护的，我直接 return ，不做任何操作，反之亦然，删除这个工作并不是 service 来完成，真正的删除是在 UserManager 和 DeptManager 中，为什么只调用某个 manager 是我们很明确其他 manager 没有和部门发生关系而已。
继续问题 1：我们目前使用一个原则来确认代码在那一层：是否抛出业务异常和 Manager 中一个方法只能对应一个动作（增/删/改）

问题 2：来个简单粗暴的，直接调用 dao 的都在 manager 中，功能权限校验/参数校验/返回结果裁剪都在 controller 中，其他的都扔在 service 中就可以了，不要过多纠结，这个没有统一标准，写的多了自然就有经验了。

@chaleaochexist 比较有争议的是这种情况，UserDao/DeptDao/UserDeptDao ，UserDao 和 UserDeptDao 肯定是直接被 UserManager 引用，现在有个需求，在部门下有人的情况下，可以直接删除部门，删除部门后，需要将部门下的人员与部门关系解除，很多人就会这样写：
class DeptManager{
void deleteDept(id){
deptDao.deleteById(id);
userDeptDao.deleteByDeptId(id);
}
}
实际上我们做法是这种；
class DeptService{
void deleteDept(id){
deptManager.deleteById(id);
userManger.deleteUserDeptByDeptId(id);
}
}
由上层去协调，如果还有业务逻辑掺杂在里面，我们还有更上层的应用层去协调：
class DeptApplication {
void deleteDept(id){
deptService.deleteById(id);
userService.deleteUserDeptByDeptId(id);
}
}

@chaleaochexist 理论上一个 dao 不会被两个 manager 调用，这个就要从上层设计来说了，领域驱动设计(DDD)应该有了解吧，我们完整的领域对象应该包括了（属性+业务方法），大概是长这个样子：
class User {
Long id;
String name;

void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
后来我们觉得应该职责分离，属性和方法分开，就变成了下面这种：
class User{
Long id;
String name;
}
class UserService extends User {
void saveUser(){
// so something
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
再后来我们觉得方法还可以继续拆，分为业务方法和非业务方法：
class UserManager extends User {
void saveUser(){
userDao.saveUser();
userDeptDao.saveUserDept();
}
}
class UserService extends UserManager {
void saveUser(){
// so something
userManager.saveUser();
}
}
看出来没有，我们所有的操作其实都围绕着 User 这个模型在工作，如果你有 UserAManager 和 UserBManager ，这两个都调用 UserDao 可以，但是你一个 DeptManager 调用 UserDao ，那就要考虑一下是不是你的模型设计有问题了？

@chaleaochexist 理论上一个 dao 不会被两个 manager 调用，这个就要从上层设计来说了，领域驱动设计(DDD)应该有了解吧，我们完整的领域对象应该包括了（属性+业务方法），大概是长这个样子：
class User {

}

@chaleaochexist 举个例子，现在我要做一个员工管理功能，员工信息是一个大表单，用户基本信息：姓名，账号……，用户其他信息：任职部门（多个），岗位（多个），紧急联系人（多个），工作经历（多个）……，因为要支持任意关联属性实时搜索，所以一般都是 1 个主表+n 个关联表，大概有 UserDao/UserDeptDao/UserPositionDao/UserContactDao/UserEmployHistoryDao ，每次保存/修改都要调用这么多 dao ，还有就是如果是更新，还需要更新缓存，更新 es ，那么我有一个 UserManager.saveUser(UserDTO user)，这个方法再调用 5 个 dao ，修改缓存/es ，上层的 service 方法就简单了，userManager.saveUser(user)即可，service 能够专注于处理业务逻辑，不关心数据存储，manager 关心数据存储，不关心业务逻辑，如果业务小体现不出来，像我们最多的一个主表对了 20 多个关联表，es ，redis ，es 都有，拆分了效果就很明显了。

@chaleaochexist 我这个 id 专门用来注册互联网用的，没有任何地方留有邮箱的。

针对你这种情况，我们一般是这样写：listOrders(OrderQuery query, QueryType queryType)，queryType 有两个值，实时查询/非实时查询，分别对应数据库/es ，manager 内部又有两个 私有 方法：listOrdersByDB ，listOrdersByES ，根据用户传入的 queryType 转调两个方法，这样就把业务屏蔽掉了，像你这种在方法命名上带业务，如果后期再来 N 角色，是不是要写 N 个方法？