根本原因是普通用户执行python script.py时，其sys.path不包含root安装包的全局site-packages路径，且可能受PYTHONNOUSERSITE、目录权限或pyvenv.cfg限制；PermissionError则源于脚本运行中访问受限系统路径。
非root用户无法启动全局安装的Python脚本，根本原因不是脚本本身有问题，而是执行时找不到解释器或依赖模块——python 命令调用的解释器路径、PYTHONPATH、sys.path 三者在 root 和普通用户间不一致，且普通用户通常无权读取全局 site-packages 中的部分文件。
为什么 python script.py 找不到模块？
root 用户用 pip install --global（或未加 --user）安装的包默认落在 /usr/local/lib/pythonX.X/dist-packages/ 或 /usr/lib/pythonX.X/site-packages/。普通用户虽然能运行 python，但其 sys.path 默认不包含这些路径，除非：
• 系统 Python 配置了 DEBIAN_FRONTEND 或 pyvenv.cfg 允许跨用户共享
• /usr/local/lib 目录权限设为 755 且组可读（很多发行版默认是 755，但某些加固系统会设成 750）
• 普通用户 shell 启动时未被覆盖掉 site 自动导入逻辑（比如用了 -S 参数或设置了 PYTHONNOUSERSITE=1）
PermissionError: [Errno 13] Permission denied 怎么来的？
这类报错常出现在脚本里调用了需要写系统目录的操作，比如：
• 日志写入 /var/log/（普通用户无权写）
• 创建缓存到 /usr/local/share/
• 调用 subprocess.run(..., shell=True) 后执行了需 root 权限的命令（如 systemctl、iptables）
注意：错误不是来自“启动脚本”，而是脚本运行中某一步触发了权限检查。用 strace -e trace=access,openat python script.py 2>&1 | grep -E '(denied|EACCES)' 可快速定位哪条路径被拒。
普通用户怎么安全运行全局脚本？
不推荐直接改全局目录权限或切 root 运行——风险高、不可复现。更务实的做法是：
• 用 python -m venv myenv && source myenv/bin/activate 创建干净环境，再 pip install --force-reinstall --no-deps package_name（只装缺失依赖，不碰系统包）
• 若脚本只是入口，把核心逻辑抽成模块，用普通用户 pip install --user 安装该模块，再写一个本地 ~/bin/myscript 包装器，第一行写 #!/usr/bin/env python3，并确保 ~/bin 在 $PATH 前端
• 对必须访问系统路径的操作，改用 sudo -n 显式提权（需提前配好 /etc/sudoers 白名单），避免整个脚本以 root 身份运行
立即学习“Python免费学习笔记（深入）”；
最容易被忽略的一点：有些“全局脚本”其实是通过 setuptools 的 entry_points 安装的命令行工具（如 black、flake8），它们的可执行文件在 /usr/local/bin/，但运行时仍会动态加载模块。此时即使 which black 能找到，black --version 仍可能报 ModuleNotFoundError——因为模块路径没进 sys.path。这种情况下，--user 安装同名包反而会覆盖全局入口，务必先 pip uninstall black 再重装。
