su是完全切换用户身份，需目标密码；sudo是精准委托权限，用自身密码并集中管控。su易泄露root密码、缺乏审计，sudo支持命令级授权与完整日志，更符合等保与最小权限原则。

Linux 中 su 和 sudo 不是“换种写法”，而是两种不同权限管理哲学的体现：su 是用户身份的完全接管，sudo 是能力的精准委托。企业环境里选错一个，轻则操作出错，重则绕过审计、暴露 root 密码、违反等保要求。

本质目标完全不同

su（switch user）的核心是“变成那个人”——输入目标用户密码后，启动一个新 shell，UID/GID、家目录、PATH、环境变量全部切换为该用户所有。默认不带参数时直奔 root，必须知道 root 密码。

sudo（superuser do）的核心是“代他做一件事”——用自己密码验证身份，临时以指定用户（通常是 root）权限执行某条命令，不切换 shell、不改变当前工作目录和大部分环境变量。

打个比方：
- su 像你刷门禁卡进 CEO 办公室，坐在他工位上用他的电脑、打开他的浏览器、访问他的收藏夹；
- sudo 像你拿着 CEO 签字的授权单，去行政部盖章、去财务领一笔款，办完就回自己工位。

密码与权限控制机制差异明显

su 要求你掌握目标账户的密码，尤其是 root 密码一旦泄露，等于交出整台服务器的钥匙；sudo 只需验证你自己的密码，权限由 /etc/sudoers 文件集中管控，离职员工账号一禁，sudo 权限自动失效。

权限粒度上：
- su 成功即获得目标用户全部权限，无法限制“能改哪些文件”“能跑什么服务”；
- sudo 支持精确到命令级的授权，例如：

• 只允许运维人员重启 nginx：alice ALL=(root) /usr/bin/systemctl restart nginx
• 让 DBA 以 postgres 用户执行备份：bob ALL=(postgres) /usr/bin/pg_dump
• 开发可免密拉取 Git 仓库：devgroup ALL=(ALL) NOPASSWD: /usr/bin/git pull

所有 sudo 操作默认记录在 /var/log/auth.log，含用户、时间、终端、完整命令，满足等保日志审计要求；su 切换本身不记录具体执行了什么，仅留登录痕迹。

环境行为决定操作稳定性

执行效果受环境加载方式直接影响：

• su（无参数）：切换 UID/GID，但保留原家目录、PATH、PS1 等——容易因路径不对导致命令找不到，比如 ls 正常，systemctl 却报 command not found
• su - 或 su -l：完整登录 shell，加载目标用户 .bashrc、.profile，环境干净统一
• sudo command：在当前环境下执行，PATH 不变，适合单步操作
• sudo -i：模拟 su - 效果，启动 root 的登录 shell，用的是当前用户密码，更安全可追溯

企业脚本或自动化中应避免 sudo su - 这类冗余组合——它先提权再切用户，既多一次密码验证，又模糊操作主体，审计日志里显示的是“sudo 执行了 su”，而非“谁执行了什么命令”。

企业级权限切换规范建议

不是“哪个好用选哪个”，而是按场景分级使用：

• 日常单步操作（编辑配置、启停服务、查日志）：一律用 sudo + 命令，如 sudo systemctl restart sshd
• 需连续执行多条命令且依赖 root 环境变量（如编译内核、调试 systemd unit）：用 sudo -i，禁止直接 su -
• 跨用户协作任务（如 web 应用以 www-data 身份运行脚本）：用 sudo -u www-data /path/to/script.sh
• 新员工入职：加入 sudo 组即可获得基础权限，usermod -aG sudo alice；禁用 root 密码，关闭 SSH root 登录
• 高危操作（rm -rf /、dd 写盘、数据库 drop）：必须通过 sudoers 显式白名单控制，禁用通配符 ALL，启用 requiretty 和 log_input/log_output

不复杂但容易忽略：真正的权限治理不在命令怎么敲，而在 /etc/sudoers 是否经 visudo 校验、是否启用日志审计、是否遵循最小权限原则。一次配置疏漏，可能让三年合规建设归零。