为何终端与Bash脚本执行sudo命令得到的PATH结果存在差异？

• 终端和脚本的运行环境存在本质差异：
  • 终端属于交互式Shell：默认会读取~/.bashrc配置，同时开启别名展开功能，因此你配置的alias sudo='sudo -i'会直接生效，输入sudo实际执行的是带-i参数的sudo -i命令。sudo -i会模拟root的完整登录环境，加载root的自定义环境配置，因此输出的PATH包含Python、JDK等自定义路径。
  • 直接执行./tmp.sh时，会启动一个独立的非交互式Shell进程：这类Shell默认有两个关键限制：
    • 不主动加载~/.bashrc等交互式Shell专属配置，根本读取不到你配置的sudo别名；
    • 即使手动加载了配置，默认也不会开启别名展开功能，不会把sudo自动替换成带-i参数的版本。
  • 脚本里实际执行的是系统原生的sudo命令：原生sudo为了安全会最小化环境变量，将PATH重置为系统默认的短路径，不会加载root的自定义环境配置，因此输出的PATH和终端的结果存在明显差异。

补充：如果在终端中通过source tmp.sh的方式运行脚本，因为是在当前交互式Shell的上下文执行，已经加载了别名配置，会和直接在终端输入命令的效果完全一致，但这不是脚本的常规运行模式。

• 方案1（最推荐，稳定性最高）：直接在脚本中使用完整命令，不依赖别名机制
  既然终端里的sudo最终会展开成sudo -i，那直接把脚本里的命令写全即可，完全绕开别名加载的限制：

  #!/bin/bash
  sudo -i env | grep PATH
  

  这种写法和用户的终端自定义配置完全解耦，不管是直接执行、被其他脚本调用，都能稳定复现预期效果，也不会引入不必要的配置加载副作用，是Shell脚本的通用最佳实践。
• 方案2（临时调试用，不推荐长期使用）：在脚本中手动开启别名加载
  如果临时需要在脚本中复用已有的别名配置，可以在脚本开头手动开启非交互Shell的别名扩展、加载对应配置：

  #!/bin/bash
  shopt -s expand_aliases  # 开启非交互Shell的别名展开功能
  source ~/.bashrc         # 手动加载bashrc中的别名和配置
  sudo env | grep PATH
  

  注意这种方式的局限性：~/.bashrc中通常包含大量仅适合交互式终端的逻辑（比如提示符设置、交互判断、提示命令），强行加载到非交互脚本中很容易引发非预期报错，稳定性较差，不适合长期运行的生产脚本使用。
• 补充说明：如果需要让sudo在所有场景下默认带-i参数，不要依赖个人用户的别名配置，可以通过修改/etc/sudoers的全局规则实现，但这种改动会影响服务器上所有用户的sudo行为，风险较高，非必要不建议操作。

内容的提问来源于stack exchange，提问作者yoon