默认不启用软链接，所谓“禁用”实为确认未被意外开启；Composer path仓库默认硬复制，仅当config中显式设"symlink": true时才尝试符号链接，且需删vendor后重装并验证ls -la无“->”才生效。
默认就不启用软链接，所谓“禁用”其实是确认它没被意外打开。 Composer 的 path 类型仓库默认行为是硬复制（copy），只有明确配置了 "symlink": true 才会尝试创建符号链接。你看到 vendor 里是软链，大概率是某处悄悄开了这个开关。
检查项目级 symlink 配置是否被显式开启
Composer 的 symlink 开关是全局生效的，但优先级顺序是：项目根目录 composer.json 中的 config.symlink > 全局配置（composer config --global）。很多人以为只改了自己项目，其实被全局配置覆盖了。
- 运行
cat composer.json | jq '.config.symlink'（Linux/macOS）或手动打开文件，查找"symlink": true是否出现在config段内 - 检查是否执行过
composer config --global symlink true—— 这会让所有项目默认走 symlink，极不推荐 - 如果发现
"symlink": true，直接改成"symlink": false（注意不是删掉字段，否则 fallback 到默认值，而默认值在部分旧版本中可能不一致）
重装依赖才能让 symlink 状态真正生效
即使改了配置，已存在的 vendor 目录不会自动转换：软链不会变复制，复制也不会变软链。Composer 不会在 update 时主动替换已有目录类型。
- 必须先删掉对应包目录：
rm -rf vendor/vendor/name（Linux/macOS）或rd /s/q vendor\vendor\name（Windows） - 再运行
composer update vendor/name（指定包名，避免误更新其他依赖） - 验证结果：
ls -la vendor/vendor/name，输出中不应出现->符号；若显示普通目录结构，说明已是硬复制
Windows 用户特别要注意权限与 fallback 静默降级
Windows 下 symlink 创建失败时，Composer 不报错，只输出一行 Creating symlink for ... failed, falling back to copy，极易被滚动日志刷走。你以为配了 symlink，其实早退到 copy 了。
- 加
-v参数重跑：composer update vendor/name -v | grep "falling back"，确认是否真 fallback - 终端必须以管理员身份运行（CMD/PowerShell），或启用 Windows “开发者模式”
- 手动测试系统能力：
cmd /c mklink /D test-link .，若提示“拒绝访问”，说明环境根本不支持 symlink，那就别配"symlink": true，避免预期与实际不符
真正容易被忽略的是：一旦 vendor/ 里已有 symlink，composer update 不会把它转成 copy；而且 symlink 只对 type: "path" 生效，对 Git 仓库、dist 包完全无效。调试时别只信 composer install 输出是否“成功”，得看 ls -la + 改本地代码后项目是否真能立刻生效。
