/etc/environment不支持$PATH扩展，因其由PAM直接读取、不经过shell解释，$PATH会被当作字面量保留；正确做法是完整列出路径，或改用支持shell语法的/etc/profile.d/*.sh方案。
全局环境变量必须写入系统级配置文件，且要区分 PATH 追加和普通变量定义的语法差异；/etc/environment 最简单但不支持 $PATH 扩展，/etc/profile.d/*.sh 是最稳妥的通用方案。
为什么 /etc/environment 不能用 $PATH 扩展
/etc/environment 由 PAM 直接读取，不经过 shell 解释器，所以所有变量都当作纯字符串处理。写 PATH="/usr/local/bin:$PATH" 会导致 $PATH 字面量保留，而不是展开成原有路径。
- 正确写法是完整列出所有路径：
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/myscripts" - 错误写法：
PATH="/usr/local/myscripts:$PATH"—— 这会让 PATH 变成字面量/usr/local/myscripts:$PATH，后续命令基本失效 - 生效方式：修改后必须重新登录或重启，
source命令完全无效
/etc/profile.d/*.sh 是推荐做法的原因
它兼容所有 Bourne-like shell（bash、dash、sh），加载时机稳定，且支持完整的 shell 语法，避免覆盖风险。
- 创建文件：
sudo nano /etc/profile.d/myscripts.sh - 内容只需一行：
export PATH="/usr/local/myscripts:$PATH" - 权限必须可读：
sudo chmod 644 /etc/profile.d/myscripts.sh（不需要 +x） - 当前会话立即生效：
source /etc/profile.d/myscripts.sh - 新用户、新登录 shell、SSH 登录都会自动加载
别在 /etc/profile 末尾硬加 export PATH
看似直接，但容易被后续 profile.d 脚本覆盖——因为 /etc/profile 会 source 所有 /etc/profile.d/*.sh，而 PATH 是最后赋值者胜出。
- 如果 /etc/profile 末尾写
export PATH="/a:$PATH"，但 /etc/profile.d/java.sh 里写了export PATH="/opt/java/bin:$PATH"，最终 PATH 以 java.sh 的为准 - 更安全的做法是：删掉 /etc/profile 里的 PATH 修改，只用 /etc/profile.d/ 管理
- 验证是否被覆盖：
echo $PATH看顺序，再检查grep -r PATH /etc/profile.d/
脚本权限和执行权限常被忽略
PATH 中的目录必须对所有目标用户可执行，脚本本身必须有 +x 权限，否则即使 PATH 正确，运行时也会报 Permission denied。
- 确认脚本可执行：
sudo chmod +x /usr/local/myscripts/myscript - 确认目录可进入：
sudo chmod 755 /usr/local/myscripts - 测试权限：
sudo -u nobody /usr/local/myscripts/myscript --help（模拟其他用户执行） - 常见坑：脚本第一行
#!/usr/bin/env bash没写，或换行符是 Windows 风格（^M），导致解释器找不到
