os.system不推荐因其本质是fork+shell解析，易遭命令注入、无法捕获输出、不能设超时、阻塞主线程且不返回结构化结果；应改用subprocess.run传列表参数并启用capture_output、text和timeout。
为什么 os.system 在多数场景下不推荐用
os.system 本质是 fork + shell 解析，它把整个命令字符串丢给 /bin/sh（或 Windows 的 cmd.exe）执行，无法直接捕获输出、判断真实退出码、控制超时，还容易被注入攻击。比如 os.system("ls " + user_input)，一旦 user_input 是 "; rm -rf /"，后果不可控。
更关键的是：它阻塞主线程、无法获取子进程句柄、不能设置环境变量隔离、也不支持流式读取大输出——这些在自动化脚本、CI 工具、服务端调用中全是硬伤。
- 不返回结构化结果，只能靠返回值粗略判断成功（0）或失败（非0）
- 标准输出/错误直接打印到终端，无法重定向或解析
- 无法设置
timeout，卡死时只能靠外部信号中断 - Windows 下对 Unicode 路径和参数的支持不稳定
用 subprocess.run 替代的最小安全写法
最常用也最稳妥的写法是显式传入命令列表（避免 shell 解析），并始终捕获输出：
import subprocess
result = subprocess.run(
["ls", "-l", "/tmp"],
capture_output=True,
text=True,
timeout=5
)
if result.returncode == 0:
print(result.stdout)
else:
print("Error:", result.stderr)
-
capture_output=True等价于stdout=subprocess.PIPE, stderr=subprocess.PIPE，必须加，否则输出会直接刷屏 -
text=True让stdout/stderr返回str而非bytes，省去.decode()步骤 -
timeout强制设一个合理值（如 3–30 秒），防止挂起；超时会抛subprocess.TimeoutExpired - 命令必须是 list 形式，
["git", "commit", "-m", "fix: ..."]安全；不要用shell=True+ 字符串拼接
需要 shell 功能时怎么安全处理
真要依赖管道、通配符、重定向（如 ls *.py | wc -l），才考虑 shell=True，但必须严格限制输入源：
立即学习“Python免费学习笔记（深入）”；
- 只对**完全可控的常量字符串**启用
shell=True，例如subprocess.run("date +%s", shell=True, text=True) - 若含用户输入，先用
shlex.quote()转义：subprocess.run(f"grep {shlex.quote(pattern)} file.txt", shell=True, ...) - 避免在
shell=True下使用env参数修改环境变量，容易覆盖关键项（如PYTHONPATH）；改用env={...}显式传入完整环境 - Windows 下
shell=True默认调用cmd.exe，不支持bash语法；如需 bash，得显式写["C:\Program Files\git\bin\bash.exe", "-c", "..."]
性能差异在哪？什么情况下反而更慢
subprocess.run 本身开销略高于 os.system（多一次 Python 层封装、对象构造），但实际差距微乎其微（通常
- 频繁调用小命令（如每秒 100+ 次
date）时，改用 Python 原生模块（datetime.datetime.now().timestamp()）比任何 shell 调用都快 - 批量操作别循环跑
run，改用单次命令聚合：比如删 100 个文件，用rm file1 file2 ...而非 100 次run(["rm", "file1"]) - 大输出不加
capture_output=True会卡住（缓冲区满后子进程暂停），看似“快”实则不可靠；真要流式处理，用subprocess.Popen配合.stdout.readline() - Linux 下若命令本身启动慢（如
java -version），换subprocess.run并不会让它变快——瓶颈在目标程序，不在调用方式
真正该花时间优化的，是减少调用次数、避免不必要的 shell 层、以及确认是否真的需要调外部命令。
