禁用服务≠停止服务，disable仅取消开机自启而不影响当前运行状态；需先stop再disable才能彻底停用。
禁用服务 ≠ 停止服务，别混淆这两步
很多人执行
后发现服务还在跑，就以为“禁用失败”——其实这是正常现象。
只影响开机自启，不碰当前运行状态。它删的是
这类软链接，和进程本身无关。
要立刻停掉正在运行的服务，必须先执行
再执行
，才算真正“既停又禁”
验证是否生效：运行
应返回
；
应返回
什么时候该用
而不是
如果你发现禁用后，服务还是被其他程序拉起来了（比如某个容器或脚本里写了
），说明
不够狠。
是唯一能彻底封死服务的手段：它在
下建一个指向
的符号链接，任何启动请求都会被 systemd 直接拒绝。
彻底锁定：
尝试启动会报错：
解除锁定需两步：
，再
（如需恢复自启）
注意：
会覆盖所有同名 unit 文件，包括 drop-in 配置，慎用于关键基础服务（如
、
）
查服务名、看依赖、防误禁，三步不能跳
直接输错服务名，
会静默失败（不报错但没效果）；更危险的是禁掉被依赖的服务，可能让网络、日志甚至 SSH 失效。
Docker Desktop（linux）
当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。
下载
查真实服务名：
（别只靠印象写
，实际可能是
或
）
看谁依赖它：
（加
才能看出哪些服务靠它活着）
确认当前没被关键链路调用：
看 Loaded 行末尾是否标了
，再结合
判断是否真在跑
改完配置必须 reload daemon，否则
可能不生效
如果你手动编辑过
文件（比如用
加了
），或者从第三方源安装了新 service 文件，systemd 不会自动感知变更。
每次修改 unit 文件后，必须执行：
否则
可能提示
，或看似成功实则链接未删除
验证 reload 是否成功：
应显示你刚改的内容；
应为空（禁用后）
禁用服务最常出问题的地方不在命令本身，而在没搞清“服务名是否准确”“有没有隐藏依赖”“unit 文件是否已重载”。尤其是
，一不小心就锁死系统关键组件，恢复时还得进 recovery mode。动手前花三十秒查依赖和状态，比重启两次系统省时间。
sudo systemctl disable nginxdisable/etc/systemd/system/multi-user.target.wants/nginx.servicesudo systemctl stop nginxsudo systemctl disable nginxsystemctl is-enabled nginxdisabledsystemctl is-active nginxinactivemaskdisablesystemctl start bluetoothdisablemask/etc/systemd/system//dev/nullsudo systemctl mask bluetooth.serviceFailed to start bluetooth.service: Unit bluetooth.service is masked.sudo systemctl unmask bluetooth.servicesudo systemctl enable bluetooth.servicemasksshdsystemd-journaldsystemctl disablesystemctl list-unit-files --type=service | grep -i "bluetooth\|cups\|avahi"bluetoothbluetooth.serviceblueman.servicesystemctl list-dependencies --reverse nginx.service--reversesystemctl status nginx | grep -A5 "Loaded:"enabledsystemctl list-units --state=running | grep nginxdisable.servicesystemctl edit --fullExecStartPre=/bin/falsesudo systemctl daemon-reloadsystemctl disableNo such file or directorysystemctl cat nginx.servicels /etc/systemd/system/multi-user.target.wants/ | grep nginxmask