su是身份切换，sudo是权限委托；企业规范强调最小权限、可审计、密码隔离和环境可控；日常运维首选sudo因其审计明确、无需root密码、权限自动回收、支持精细授权。
区分 su 和 sudo 的核心在于：一个是“换人”，一个是“借权”。su 是身份切换，直接变成另一个用户；sudo 是权限委托，以当前身份临时获得执行特定命令的权限。企业级规范围绕最小权限、可审计、密码隔离和环境可控这四点建立。
什么时候该用 su -，而不是 su 或 sudo
需要完整加载目标用户的登录环境时，必须用 su -（或 su -l）。
- 部署服务前初始化系统用户：比如创建
redis用户并配置/opt/redis目录，依赖/root/.bashrc中定义的PATH或自定义函数，用普通su会因路径缺失导致chown或systemctl找不到命令 - 调试某个用户专属环境问题：例如
www-data用户启动失败，需模拟其完整 shell 初始化流程，检查~/.profile是否被正确读取 - 执行一连串强环境依赖操作：如编译安装软件、运行旧版脚本，这些脚本硬编码了
$HOME或调用了/usr/local/bin下的工具，而该路径只在目标用户PATH中
为什么日常运维首选 sudo，而不是 su
sudo 不是“替代 su”，而是解决 su 在企业场景中的三个硬伤：密码共享、操作不可溯、权限收不回。
- 审计明确：每条
sudo command都记入/var/log/auth.log，含时间、发起用户、终端、命令全路径，满足等保和 SOC2 合规要求 - 无需 root 密码：员工只需自己密码即可提权，避免 root 密码在团队中流转、截图、粘贴泄露
- 权限自动回收：默认 15 分钟无操作后失效，不会像
su -那样长期滞留在 root shell 中，误删/或覆盖关键配置的风险大幅降低 - 支持精细授权：可在
/etc/sudoers中限定某用户只能重启 nginx、只能读取日志、只能执行备份脚本，不给ALL
企业级权限切换安全规范要点
不是靠“记住哪个命令更好”，而是靠机制设计堵住漏洞。
- 禁用 root 远程登录：修改
/etc/ssh/sshd_config中PermitRootLogin no，强制所有管理走普通用户 + sudo - 全员加入 sudo 组，而非 wheel：Ubuntu/Debian 默认用
sudo组，执行usermod -aG sudo username即可，比手动配sudoers更可控 - 禁止裸 sudo 权限：不用
NOPASSWD: ALL，至少保留密码验证环节；对自动化任务，用sudo -n+ 限定命令白名单 - 限制 su 使用范围：启用
pam_wheel，仅允许wheel组成员执行su -，再把极少数高级运维加入该组 - 禁用交互式 shell 授权：在
sudoers中不开放/bin/bash、/usr/bin/python3等，防止通过sudo python3 -c "import pty; pty.spawn('/bin/bash')"绕过命令级限制
一个典型误用对比：查日志 vs 调整服务
同样是“要干 root 才能干的事”，选法完全不同。
-
错误做法：用
su -登录 root，然后tail -f /var/log/nginx/error.log→ 查完忘记exit，后续rm -rf或git push全在 root 下执行，污染归属、埋下误操作隐患 -
正确做法：用
sudo tail -f /var/log/nginx/error.log→ 查完自然回到当前用户，环境干净，日志可查谁、何时、查了什么 -
错误做法：用
sudo systemctl restart nginx后，顺手cd /etc/nginx再vim nginx.conf→ 后者仍是普通权限，编辑失败还可能触发奇怪的权限报错 -
正确做法：若需连续编辑+重载，应统一用
sudo -i进入 root shell（明确上下文切换），或拆成两条带 sudo 的命令：sudo vim /etc/nginx/nginx.conf && sudo systemctl reload nginx
