修复 YOLOFuse 中 python 命令缺失的软链接方法
在多模态目标检测项目里，最容易把人拦住的，往往不是模型结构，而是环境。YOLOFuse 的依赖装好了，CUDA、PyTorch、Ultralytics 也都能用，结果一跑推理脚本就报：
sh: 1: python: not found
或者：
/usr/bin/python: No such file or directory
这类报错很烦人，因为代码看起来没问题，真正断掉的是系统里那个默认的 python 入口。对精简镜像、容器环境，或者 Kaggle、Hugging Face Spaces 这类平台来说，这种情况并不罕见。
YOLOFuse 基于 Ultralytics YOLO，做的是 RGB 和红外图像的双流融合检测。模型本身当然是重点，但它的启动脚本还是会按老习惯去找 python。如果系统里只有 python3，没有 python，脚本就会卡在入口。
最直接的处理方式，就是补一条软链接：
ln -sf /usr/bin/python3 /usr/bin/python
这条命令的意思很简单：把 /usr/bin/python 指到 /usr/bin/python3。-s 表示创建符号链接，-f 表示如果原来已经有同名文件或链接，就直接覆盖。对这种'只差一个名字'的问题，这通常是最快的修法。
运行前可以先看一下当前环境里到底有没有 python：
which python
python --version
ls -l /usr/bin/python
如果链接建好了，ls -l 的结果一般会像这样：
lrwxrwxrwx 1 root root 16 Apr 5 10:00 /usr/bin/python -> /usr/bin/python3
之后再执行：
python infer_dual.py --weights yolofuse_dual.pt --source data/test/
就能走到真正的推理逻辑了。
这类修复有几个明显好处：不用改源码，不影响项目原本的脚本结构，而且对整个环境都生效。代价也很直接——你在动的是系统级路径，所以别拿它随便往共享生产机上塞。对容器、实验机、单用户开发环境来说，这种做法很省事；对多人共用机器，就得更谨慎一点。
如果你是在构建镜像，最好把这一步直接写进 Dockerfile：
RUN ln -sf /usr/bin/python3 /usr/bin/python
这样镜像启动后就不会再在入口处掉链子。这个思路比让每个使用者手工修一次要稳得多。
也可以把修复逻辑放到启动脚本里，只在缺失时才创建链接：
if ! command -v python &> /dev/null; then
echo "Python command not found. Creating symlink to python3..."
ln -sf /usr/bin/python3 /usr/bin/python
fi
这样做的好处是比较克制，不会每次都重复操作。放在 CI/CD、容器启动脚本或者一键部署流程里都说得通。
