禁用服务≠停止服务，disable仅取消开机自启而不影响当前运行状态；需先stop再disable才能彻底停用。
禁用服务 ≠ 停止服务，别混淆这两步
很多人执行 sudo systemctl disable nginx 后发现服务还在跑，就以为“禁用失败”——其实这是正常现象。disable 只影响开机自启，不碰当前运行状态。它删的是 /etc/systemd/system/multi-user.target.wants/nginx.service 这类软链接，和进程本身无关。
- 要立刻停掉正在运行的服务，必须先执行
sudo systemctl stop nginx - 再执行
sudo systemctl disable nginx，才算真正“既停又禁” - 验证是否生效：运行
systemctl is-enabled nginx应返回disabled；systemctl is-active nginx应返回inactive
什么时候该用 mask 而不是 disable
如果你发现禁用后，服务还是被其他程序拉起来了（比如某个容器或脚本里写了 systemctl start bluetooth），说明 disable 不够狠。mask 是唯一能彻底封死服务的手段：它在 /etc/systemd/system/ 下建一个指向 /dev/null 的符号链接，任何启动请求都会被 systemd 直接拒绝。
- 彻底锁定：
sudo systemctl mask bluetooth.service - 尝试启动会报错：
Failed to start bluetooth.service: Unit bluetooth.service is masked. - 解除锁定需两步：
sudo systemctl unmask bluetooth.service，再sudo systemctl enable bluetooth.service（如需恢复自启） - 注意：
mask会覆盖所有同名 unit 文件，包括 drop-in 配置，慎用于关键基础服务（如sshd、systemd-journald）
查服务名、看依赖、防误禁，三步不能跳
直接输错服务名，systemctl disable 会静默失败（不报错但没效果）；更危险的是禁掉被依赖的服务，可能让网络、日志甚至 SSH 失效。
- 查真实服务名：
systemctl list-unit-files --type=service | grep -i "bluetooth\|cups\|avahi"（别只靠印象写bluetooth，实际可能是bluetooth.service或blueman.service） - 看谁依赖它：
systemctl list-dependencies --reverse nginx.service（加--reverse才能看出哪些服务靠它活着） - 确认当前没被关键链路调用：
systemctl status nginx | grep -A5 "Loaded:"看 Loaded 行末尾是否标了enabled，再结合systemctl list-units --state=running | grep nginx判断是否真在跑
改完配置必须 reload daemon，否则 disable 可能不生效
如果你手动编辑过 .service 文件（比如用 systemctl edit --full 加了 ExecStartPre=/bin/false），或者从第三方源安装了新 service 文件，systemd 不会自动感知变更。
- 每次修改 unit 文件后，必须执行：
sudo systemctl daemon-reload - 否则
systemctl disable可能提示No such file or directory，或看似成功实则链接未删除 - 验证 reload 是否成功：
systemctl cat nginx.service应显示你刚改的内容；ls /etc/systemd/system/multi-user.target.wants/ | grep nginx应为空（禁用后）
mask，一不小心就锁死系统关键组件，恢复时还得进 recovery mode。动手前花三十秒查依赖和状态，比重启两次系统省时间。 
