改完配置没生效：reload 与 restart 的区别
有一类错误会反复出现：配置文件明明改对了，服务行为却没变。它之所以难查，是因为没有任何报错——文件是对的，进程也是活的，只是进程还在用旧配置。
三件不同的事
| 命令 | 作用 | 什么时候用 |
|---|---|---|
daemon-reload | 让 systemd 重读 .service 单元文件 | 改的是单元文件本身（端口、环境变量、依赖） |
reload | 进程收到信号后重读自己的配置，连接不断 | 改的是服务自己的配置文件，且服务支持热加载 |
restart | 停掉进程再起一个，连接会断 | 服务不支持 reload，或改了监听地址一类无法热加载的项 |
一个真实的连锁反应
把某个服务改成由 systemd 托管时，如果单元文件里写了 After= 之类的依赖，那么停止旧容器就会顺带把新服务一起拉停。表现是：服务启动成功、systemctl status 也显示 active，但几分钟后又没了。
这类问题不是靠 "再启动一次" 解决的，而是要把依赖关系理清楚：谁真的依赖谁，谁只是碰巧被写在了同一个单元里。
把「生效」当成独立一步
我的做法是把每次变更拆成固定的五步，缺一步都不算完成：
- 先看：改动前记录当前状态（版本、监听、进程）。
- 改：只改一个变量，便于归因。
- 生效：显式 reload 或 restart，并确认命令确实执行了。
- 验：用可量化的指标验收，不看状态码、不看文件是否存在。
- 落盘：把改动、原因和回退方法写进文档。
改配置不等于生效。 把「生效」写成流程里独立的一步，比指望自己每次都记得更可靠。