Composer对path仓库默认尝试创建符号链接，但仅当系统支持、未禁用且包非dist类型时生效；验证方式是用ls -la查看vendor下目录是否含“->”指向源路径，否则为复制模式。

用 ls -la 直接看 vendor 下的包目录

Composer 对 path 类型仓库默认创建符号链接（symlink），但只在满足条件时生效：系统支持、未禁用、且包未被标记为 dist。最直接的验证方式就是进终端看文件类型。

• 运行 ls -la vendor/vendor/name（Linux/macOS）或 dir vendor\vendor\name（Windows）
• 若输出中含 -> 符号（如 vendor/name -> /absolute/path/to/my-package），说明是软链
• 若显示普通目录结构（无 ->），则可能是：symlink: false 显式关闭、Windows 未启用开发者模式、或路径权限不足导致 fallback 到复制

composer show --path 显示的路径不等于实际链接目标

composer show --path vendor/name 返回的是包“安装后所在位置”的路径，即 vendor/vendor/name 这个路径本身——它不告诉你这个路径底下是真实文件还是软链。你看到 /project/vendor/monolog/monolog，不代表代码真在那里；它可能只是指向 /packages/monolog 的符号链接。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 该命令结果始终是项目内 vendor/ 下的路径，无论底层是 symlink 还是 dist 复制
• 想确认是否链接到本地源码，必须配合 ls -la 或 readlink -f vendor/vendor/name（Linux/macOS）
• 在 Docker 或 WSL 中，ls -la 可能显示 <symlink> 但 readlink 失败——说明宿主机路径挂载不一致，链接目标不可达

CI/CD 或 Windows 环境下链接常失效，别信 composer install 输出

Composer 在 install 时不会校验 symlink 是否真正可用，它只按 composer.lock 记录重建路径。这意味着：即使 vendor/name 显示为软链，运行时仍可能报 Class not found 或 file not found。

• CI 环境中 repositories.path 指向的目录往往不存在，此时 Composer 会静默 fallback 到 dist 安装（如果包有 dist 配置），或直接失败
• Windows 上未启用开发者模式时，mkdir 和 symlink 权限被拒，Composer 不报错但改走复制逻辑
• 验证是否真链接成功，不能只看 install 是否“没报错”，而要看 ls -la + 修改本地源码后项目中是否立即生效

想强制禁用软链？配置 "symlink": false 要写对位置

在 repositories 的单个 path 条目里加 options，不是全局 config。写错位置会导致完全忽略。

• 正确写法：

  {
    "type": "path",
    "url": "../my-package",
    "options": {
      "symlink": false
    }
  }

• 错误写法：把 "symlink": false 放到 config 或顶层 options，它不会作用于 path 包
• 加了之后，vendor/vendor/name 就是完整复制的文件，改本地源码不会影响项目，必须 composer update vendor/name 才同步

真正容易被忽略的是：软链存在 ≠ 软链可用。路径可读、符号链接可解析、PHP 进程能访问目标目录——这三个条件缺一不可，尤其在容器、跨平台共享目录、或权限受限的 CI 环境里。