Composer update不更新软链接，因其仅按composer.lock和仓库配置判断是否满足版本约束（如"dev-main"），若本地目录仍匹配则跳过重建； symlink是文件系统映射而非版本状态，断链或fallback多因本地包无git commit、主项目未配"options":{"symlink":true}或Windows未管理员运行。
Composer 软链接本身不会自动更新 —— 它只是个指向本地目录的符号链接，改代码立刻生效，但换分支、切版本、重装依赖时必须手动干预，否则链接可能断开或 fallback 到复制模式。
为什么 composer update 不更新软链接？
因为软链接（symlink）不是 Composer 的“版本状态”，而是文件系统层面的路径映射。当你运行 composer update vendor/name 时，Composer 只会检查 composer.lock 和仓库配置，若它判断当前 symlink 指向的目录仍满足 require 中的约束（比如 "dev-main"），就不会重建链接；但如果本地包没 commit、git 状态异常，或主项目 composer.json 里漏了 "options": {"symlink": true}，Composer 就会悄悄 fallback 成 copy 模式，导致后续修改不生效。
- 验证是否真在用 symlink：
ls -la vendor/vendor/name（macOS/Linux）输出应含->；Windows 用dir vendor\vendor\name看是否标<symlinkd></symlinkd> - 常见静默失败原因：本地包目录没
git init && git commit -m "init"、主项目config里写了"symlinks": false、Windows 未以管理员身份运行终端 -
composer install也不会重建 symlink —— 它只按composer.lock还原，而 lock 文件里不记录 symlink 状态
手动触发软链接更新的三种场景
真正需要“更新软链接”的时刻，其实是以下三种情况之一：
-
本地包切换了 Git 分支：进本地包目录，
git checkout dev-feature，然后回主项目执行composer update vendor/name（确保require写的是"dev-feature"） -
主项目改了
repositories配置：比如把"url": "../old-package"改成"url": "../new-package"，必须运行composer update vendor/name才会重新解析并重建 symlink -
想强制刷新 symlink（绕过缓存判断）：先删掉
vendor/vendor/name，再运行composer update vendor/name—— 这是最稳妥的“重连”方式
composer link 命令到底能不能用？
composer link 是个易误用的命令：它只对已安装包生效，且不写入 composer.lock，也不保证 autoload 一致。截至 2026 年 10 月，Composer 2.4+ 已内置支持，但仍有硬性前提：
- 必须先用
composer require vendor/name安装过该包（哪怕只是dev-main） - 本地包目录下要能执行
composer link（需有合法composer.json且name字段与主项目 require 完全一致） - 主项目执行
composer link vendor/name后，vendor/vendor/name才会变成 symlink；但下次composer update极可能把它覆盖回 copy 模式 - 不推荐在 CI 或团队协作中使用 —— 它绕过了 lock 文件，无法复现
真正可靠的“热更新”，靠的不是某个命令，而是 path 仓库 + 显式 "options": {"symlink": true} + 本地包带 git commit 的组合。少一个环节，就容易卡在“改了代码却没生效”的状态里。
