最安全推荐的做法是用 systemctl edit 创建 drop-in 覆盖配置，它不修改原始单元文件（如 /usr/lib/systemd/system/nginx.service），避免包管理器升级覆盖，且支持增量叠加与审计；执行 sudo systemctl edit nginx 会自动创建 /etc/systemd/system/nginx.service.d/override.conf，仅需在其中指定节名（如 [service]）和要覆盖的键值对，保存后 systemd 自动生效，验证可用 systemctl cat nginx 和 systemctl status nginx。
直接用 systemctl edit 创建 drop-in 覆盖配置，是最安全、推荐的做法。它不碰原始单元文件（比如 /usr/lib/systemd/system/nginx.service），避免被包管理器升级覆盖，还能清晰审计修改内容。
查看当前生效的完整配置
运行命令确认服务当前实际加载的配置来源：
-
systemctl cat nginx—— 输出主 unit 文件 + 所有已加载的 drop-in 片段（如/etc/systemd/system/nginx.service.d/override.conf） - 注意观察输出中是否包含
[Unit]、[Service]等节，以及你关心的字段（例如Environment=或Restart=） - 如果已有其他
.conf文件在.d/目录下，它们也会被合并显示，方便整体判断
用 systemctl edit 创建覆盖文件
执行以下命令会自动创建或打开 drop-in 文件：
-
sudo systemctl edit nginx→ 编辑器打开/etc/systemd/system/nginx.service.d/override.conf - 只写你想改或新增的部分，必须明确指定节名，例如：
[Service] Environment="NGINX_ENV=prod" Restart=always LimitNOFILE=65536
- 保存退出后，systemd 自动生效，无需手动 reload
- 覆盖是按指令粒度进行的：只影响你写出的键值对，其余配置仍继承原始文件
- 如果是列表类参数（如
Wants=），需先清空再重写，例如：Wants=后跟新值
验证和维护覆盖配置
修改后建议立即验证是否按预期生效：
- 再次运行
systemctl cat nginx，确认你的override.conf内容已出现在输出末尾，且格式正确 - 检查服务状态：
systemctl status nginx，留意 Environment、Restart 等字段是否已更新 - drop-in 文件路径固定为
/etc/systemd/system/<unit>.service.d/override.conf</unit>，也可手动创建其他.conf文件（如env.conf），systemd 会按字母顺序合并 - 如需撤销修改，直接删掉对应
.conf文件，再执行systemctl daemon-reload（仅在手动删文件后需要）
为什么不能直接编辑原始单元文件
系统自带服务的单元文件（如 /usr/lib/systemd/system/mysqld.service）由包管理器管理：
- 下次升级 MySQL 或 Nginx 时，该文件大概率被新版本覆盖，你的修改就丢失了
- 直接修改还可能破坏包校验，影响系统一致性与安全审计
- drop-in 方式天然支持增量叠加、多人协作、版本控制，也便于后续排查和回滚
