composer核心是声明依赖与自动加载，非打包工具；autoload必须正确配置psr-4（如"mycorpcore": "src/"）或files，否则类/函数无法加载，且需运行dump-autoload生效。
Composer 不是用来“打包发布”的工具，而是用来“声明依赖关系 + 自动加载代码”的协作机制；想靠它打造企业级核心包，关键不在怎么打包，而在怎么设计接口、约束版本、隔离变更。
composer.json 的 autoload 配置决定你的类能不能被自动加载
很多人把公共逻辑扔进 src/ 就以为完事了，结果在项目里 new UtilsDateHelper() 报错 Class not found——根本原因是没配 autoload。
-
"autoload": { "psr-4": { "MyCorp\Core\": "src/" } }是最常用且推荐的方式，命名空间前缀必须和目录结构严格对应 - 别用
classmap扫描整个src/，它不支持命名空间推导，且每次composer dump-autoload都要重新扫描，CI 构建慢 - 如果包内有函数文件（比如
src/functions.php），得用files字段显式声明："autoload": { "files": ["src/functions.php"] }，否则函数不会被加载
版本号不是随便写的：dev-main 和 v1.2.3 在依赖解析中行为完全不同
你 push 到 GitHub 的分支名、tag 名，直接决定下游项目能否稳定安装。用错版本标识会导致 composer install 随机失败或锁定到不可控的 commit。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 日常开发用
dev-main（或dev-develop）没问题，但上线前必须打语义化 tag：git tag v1.2.3 && git push --tags - 下游项目写
"mycorp/core": "^1.2"，Composer 才会按 semver 规则匹配v1.2.3、v1.2.9，但跳过v2.0.0 - 千万别在
composer.json里写"mycorp/core": "dev-main"上生产环境——它不锁定 commit，下次部署可能拉到未测代码
私有包不能只靠 repositories，还要处理认证和镜像源失效问题
把包放公司 GitLab 或私有 Packagist，不代表下游项目就一定能装上。常见卡点是权限、网络、以及 Composer 缓存行为。
- GitLab 私有仓库需在
auth.json中配置 token：{"gitlab-token":{"gitlab.com":"abc123..."}}，且该文件必须放在 COMPOSER_HOME 目录下（通常是~/.composer/auth.json） - 若用自建 Satis 或 Private Packagist，记得在
repositories中指定"type": "composer"，而不是"type": "vcs"，否则元数据不会被缓存 - 本地开发时偶尔遇到
Could not fetch https://xxx/p2/mycorp/core.json，先运行composer clear-cache，再确认私有源是否返回 200 且 JSON 格式合法
真正难的不是怎么发一个包，而是当 MyCorpCore 被 37 个项目引用后，改一行 Config::get() 的默认值，会不会导致某个老系统登录页白屏——这需要接口契约意识、向后兼容测试、以及比 composer update 更重的发布纪律。
