根本原因是容器中/usr/local/bin未在PATH中或软链接指向的composer.phar无执行权限；正确做法是用官方安装命令自动完成下载、校验、移动和赋权，避免软链接依赖风险。
为什么composer软链接在容器里总报command not found
不是软链接没建，而是容器启动时/usr/local/bin不在$PATH里，或者软链接指向的composer.phar权限不可执行。官方PHP镜像（如php:8.3-cli）默认不带composer命令，你手动ln -s /app/composer.phar /usr/local/bin/composer后仍失败，大概率是这两个原因。
ln -s前必须确认目标文件可执行且路径可访问
软链接只是跳转，它不解决底层依赖。如果/app/composer.phar本身没有+x权限，或它依赖的php命令不在$PATH中，软链接照样跑不起来。
- 进容器验证：
ls -l /usr/local/bin/composer看是否真指向.phar文件，且file /app/composer.phar返回“PHP script”而非“data” - 必须加权限：
RUN chmod +x /app/composer.phar，否则即使链接对了也执行失败 - 别用相对路径：
ln -s composer.phar /usr/local/bin/composer在不同WORKDIR下会断，务必用绝对路径
更稳的做法：别用ln -s，直接COPY或--install-dir
软链接在Docker里属于“绕路解法”，容易因构建层顺序、挂载覆盖、多阶段COPY丢失而失效。生产环境应避免。
- 推荐用官方安装方式：
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer——它自动完成下载、校验、移动、赋权 - Alpine用户可用
COPY --from=composer:latest /usr/bin/composer /usr/local/bin/composer，比自己建软链接可靠得多 - 如果非要用软链接，确保它写在
RUN指令里，且在WORKDIR和PATH设置之后；不要指望docker run -v挂载进来的软链接能跨用户生效
验证composer是否真可用，不能只看which
which composer返回路径不代表能运行，得实际执行并检查退出码。
- 正确验证命令：
docker run --rm php:8.3-cli sh -c 'composer --version 2>/dev/null && echo ok || echo fail' - 常见假成功：软链接存在，但
composer --version报Could not open input file——说明php找不到composer.phar，本质是php二进制路径或PHPRC干扰 - Alpine下还要确认
ca-certificates已装，否则HTTPS请求失败，软链接再对也没用
软链接本身不难，难的是它依赖的每个环节都在容器里被隔离了一次。真正省事的方式，是放弃软链接，用官方安装路径或COPY --from这种原子操作。
