YOLOFuse 环境修复命令：ln -sf /usr/bin/python3 /usr/bin/python 深度解析
在部署多模态目标检测项目时，你是否曾遇到过这样的场景？所有依赖都已安装完毕，CUDA、PyTorch、Ultralytics 也都配置妥当，信心满满地运行 python infer_dual.py，结果终端却冷冷地抛出一句：
sh: 1: python: not found
或者更让人摸不着头脑的：
/usr/bin/python: No such file or directory
代码没问题，模型权重也加载了——问题竟出在一个看似'无关紧要'的系统路径上。这正是许多开发者在使用 YOLOFuse 社区镜像时可能遭遇的'最后一公里'困境。
YOLOFuse 是一个基于 Ultralytics YOLO 架构设计的开源项目，专注于 RGB 与红外（IR）图像的双流融合检测，在低光照、烟雾遮挡等复杂环境中展现出远超单模态模型的鲁棒性。其预构建镜像本应实现'开箱即用'，但偏偏就是那一行提示缺失 python 命令，让不少初学者卡在起点。
而解决这个问题的核心，往往只靠这一条命令：
ln -sf /usr/bin/python3 /usr/bin/python
别看它短，背后牵涉的是 Linux 系统调用机制、Python 多版本共存策略以及 AI 工程实践中至关重要的兼容性设计。
我们不妨从一个实际案例切入。假设你在 Kaggle 或 Hugging Face Spaces 上启动了一个自定义容器环境，系统中已经安装了 Python 3.9，并可通过 python3 script.py 正常执行脚本。但当你尝试运行 YOLOFuse 的推理脚本时：
python infer_dual.py --weights yolofuse_dual.pt --source data/test/
Shell 却无法识别 python 这个命令。原因很简单：python 并不是一个默认存在的可执行文件链接，尤其是在现代 Linux 发行版和精简镜像中。
Python 官方早在 PEP 394 中就明确指出：python 应被视为指向 Python 2 或 Python 3 的符号链接，具体行为取决于系统配置。而在 Python 2 已被正式弃用（2020 年）之后，越来越多的系统选择不再自动创建 python → python3 的映射，转而要求用户显式调用 python3。
这就带来了一个现实矛盾：虽然新规范推荐使用 python3，但大量遗留脚本、框架入口、自动化工具仍沿用 python 作为默认解释器调用方式。YOLOFuse 的训练与推理脚本也不例外——它们依赖于标准的 shebang 写法或 shell 调用习惯。
例如，脚本首行可能是：
#!/usr/bin/env python
这个 shebang 的含义是：'请找到当前环境中的 python 命令并执行'。如果系统 PATH 中没有名为 python 的可执行程序，哪怕 python3 存在，也无法启动。
于是，软链接成了最轻量、最高效的桥梁。
执行：
ln -sf /usr/bin/python3 /usr/bin/python
本质上是在 /usr/bin/ 目录下创建一个名为 python 的'快捷方式'，让它指向真实的 python3 二进制文件。参数 -s 表示这是符号链接（软链接），而非硬链接； 则表示强制覆盖已有同名文件或链接——确保无论之前是否存在冲突，都能正确建立映射。