关键不是“有没有配置”，而是“在哪个环节、以什么身份、用什么环境执行的”：开机启动项（如rc.local、systemd service、init.d脚本）默认不加载用户shell配置文件（~/.bashrc等），PATH、HOME、USER等变量常缺失或极简，需通过日志抓取真实环境、显式声明Environment或使用绝对路径解决。
排查开机启动项环境变量缺失，关键不是“有没有配置”，而是“在哪个环节、以什么身份、用什么环境执行的”。很多脚本手动能跑，一放进开机流程就失败，90% 是因为 PATH、HOME、USER 等基础变量压根没加载，或加载顺序错乱。
确认脚本实际执行的 Shell 类型和初始化路径
开机启动项（如 /etc/rc.local、systemd service、/etc/init.d/xxx）默认不走用户登录流程，因此不会自动 source ~/.bash_profile 或 ~/.bashrc。必须明确它触发的是登录 Shell 还是非登录 Shell：
- rc.local：由 systemd 的 rc-local.service 启动，默认使用 /bin/sh（非 bash），且不加载任何用户 profile
- systemd service：ExecStart 执行时，环境极干净，只继承 minimal 系统变量（PATH 通常仅为 /usr/local/bin:/usr/bin:/bin）
- init.d 脚本：在 SysVinit 或 BusyBox 环境中，由 init 进程直接调用，PATH 常为空或仅含 /sbin:/usr/sbin
验证当前启动环境的真实变量值
不要靠猜，用可落地的日志方式“抓现场”：
- 在你的启动脚本开头插入日志语句，例如：
echo "[$(date)] PATH=$PATH, USER=$USER, HOME=$HOME, SHELL=$SHELL" >> /tmp/boot_env.log 2>&1 - 对 systemd service，可在 [Service] 段显式声明环境：
Environment="PATH=/usr/local/bin:/usr/bin:/bin:/home/user/bin"
Environment="HOME=/home/user"
Environment="USER=user" - 若需完整模拟 cron 或 rc.local 的执行环境，可用：
env -i /bin/bash -c 'echo $PATH'（-i 表示清空所有 inherited 变量）
修复路径与命令找不到的核心方法
环境变量缺失导致“command not found”，本质是执行时找不到二进制文件。解决思路不是硬塞 PATH，而是让依赖明确、可靠：
- 所有命令尽量写绝对路径：用 /usr/bin/python3 替代 python3，用 /bin/ls 替代 ls
- 若必须扩展 PATH，在脚本开头尽早设置（注意 sh 和 bash 语法兼容性）：
export PATH="/usr/local/bin:/usr/bin:/bin:$PATH" - 对 systemd service，推荐用 ExecStartPre 预检依赖：
ExecStartPre=/bin/sh -c 'command -v python3 > /dev/null || exit 1' - 避免依赖 ~ 符号：cron 和 rc.local 中 ~ 不展开，一律写成 /home/username/...
检查系统级环境配置是否被覆盖或跳过
/etc/environment 和 /etc/profile.d/*.sh 是全局生效点，但它们的加载时机受初始化系统制约：
- /etc/environment：由 PAM 模块加载，只支持 KEY=VALUE 静态赋值，不支持变量展开或命令替换，适合设 JAVA_HOME、LANG 等
- /etc/profile.d/myenv.sh：会被 /etc/profile 自动 source，但仅对登录 Shell生效；systemd service 不读它
- 若你在 ~/.bashrc 里设置了 PATH，而 rc.local 或 service 并不加载它——那就别指望它起作用
