path仓库必须配置在repositories数组中而非require字段，需声明"type": "path"及合法url，且本地包composer.json的name、version（或dev-main）、autoload必须完备，否则无法识别或类加载失败。
path 仓库必须写在 repositories 数组里，不是 require 里
很多人直接在 require 字段里加 "myorg/my-package": "./packages/my-package"，这完全不生效。Composer 根本不解析 require 中的路径字符串——它只认 repositories 块里声明的源。
正确做法是把本地包声明为一个独立仓库：
{
"repositories": [
{
"type": "path",
"url": "./packages/my-package"
}
],
"require": {
"myorg/my-package": "*"
}
}
url 必须是相对或绝对路径，不能带 file:// 前缀；myorg/my-package 必须和本地包 composer.json 里的 name 完全一致。
本地包必须有合法 composer.json，且含 name + version（或分支别名）
Composer 不会加载纯代码目录。目标文件夹下必须有 composer.json，且至少包含：
-
name：格式为vendor/name，不能和 Packagist 上已有包重名 -
version或可用分支名（如"dev-main"）：若没写version，你require时就得用"dev-main"这类明确分支别名，"*"或"^1.0"会静默失败 -
autoload：比如"psr-4": {"MyOrg\MyPackage\": "src/"}，否则类找不到
另外，该目录必须是 Git 仓库（哪怕空提交）：运行 git init && git add . && git commit -m "init" 即可，否则 Composer 拒绝识别。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
执行 require 后是软链还是复制？改代码是否实时生效？
Linux/macOS 下默认创建符号链接，Windows 下默认硬拷贝到 vendor/。这意味着：
- 改本地包源码，主项目中调用的类会立即反映变更（无需
composer dump-autoload） - 但如果你改了本地包的
autoload映射或新增了类文件路径，必须运行composer dump-autoload才能更新自动加载映射 - 如果只是临时调试，不希望影响 vendor，可用
composer install --no-dev --no-scripts避免触发清理逻辑
注意：composer update myorg/my-package 会重新建立链接/拷贝，但 composer update 全量执行时，path 类型包默认被跳过（除非显式指定）。
CI/CD 和上线前最容易忽略的三个点
path 类型仓库在持续集成中基本不可用，也绝不能进生产环境：
- CI 环境通常禁用插件或设
COMPOSER_DISALLOW_PLUGINS=1，导致 path 源被忽略，composer install直接报错“Could not find package” - 上线前必须删掉
repositories里的 path 条目，并把require改成真实版本号（如"myorg/my-package": "^2.1"），再推送到私有 Packagist 或 GitHub tag - 若本地包用了
require-dev或自定义脚本（如post-install-cmd），这些在 path 模式下完全不执行——它们只在 dist 包安装流程中触发
真正上线前的最后一验：运行 composer show myorg/my-package，确认输出里 source 字段不是 path，而是 dist 或 vcs。
