Composer项目只有库和应用两种合法形态：composer.json必须置于根目录，vendor/须同级且.gitignore排除；PSR-4映射、命名空间、文件路径三者须严格对齐；库不生成vendor/，应用需提交composer.lock并禁用dev依赖。
Composer 工程结构没有“标准模板”，只有两种合法形态：库（library）和应用（application），选错就全盘失效。
composer.json 必须放在项目根目录，否则所有命令都会出错
Composer 不会向上查找父目录，也不会向下扫描子目录。把 composer.json 放进 src/ 或 app/ 里，执行 composer install 就会报错或生成错位的 vendor/ 路径。
- 验证方法：运行
pwd确认当前路径，再检查该目录下是否存在composer.json；不存在就别硬跑命令 - 库项目（如
monolog/monolog）根目录只放composer.json、src/、tests/，不生成也不提交vendor/ - 应用项目（如 Laravel 项目）根目录必须同时存在
composer.json和vendor/（但vendor/必须被.gitignore排除） - CI 流水线中若找不到
composer.json，composer install会 fallback 到 packagist.org，私有包直接报Could not find package
PSR-4 autoload 映射必须与命名空间、文件路径三者严格对齐
写对 "psr-4": {"App": "src/"} 不代表能自动加载——它只是告诉 Composer：“当代码里 new AppHttpControllerHome(); 时，去 src/Http/Controller/Home.php 找。”
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 类文件里的
namespace声明必须以映射前缀开头，且结尾带反斜杠（如AppHttpController），不能是AppHttpController（少反斜杠）或AppHttpControllers（多 s） - 目录结构必须完全匹配：如果
composer.json写的是"App\": "src/"，就不能在src/下混放VendorLib类 - 改了目录名或命名空间后，必须立刻运行
composer dump-autoload -o，否则开发时类找不到，但错误提示可能指向其他地方（比如 autoloader 缓存未更新）
vendor/ 目录的位置和提交策略由项目类型决定，不能凭感觉忽略
vendor/ 是构建产物，不是源码。它的内容由 composer.lock 精确控制，手动修改或提交只会制造冲突、误导新人、增大仓库体积。
- 应用项目：
vendor/必须与composer.json同级，且必须写入.gitignore；否则 CI 构建时可能因本地残留包导致依赖解析失败 - 库项目：根本不会生成
vendor/，因为依赖由使用者安装；如果误执行composer install，反而会污染发布包 - 前端资源（如 JS/CSS）必须物理隔离：不能放在
vendor/下，也不能和 PHP 源码混在同一个composer.json中管理；建议用 npm/yarn 或单独的构建流程处理
团队协作中最容易被跳过的一步：全局启用 sort-packages
没开 "config": { "sort-packages": true }，不同人执行 composer require 会导致 composer.lock 中包顺序不一致，Git 一眼标红——但实际依赖树可能完全一样。
- 新成员加入前，必须运行
composer config -g sort-packages true，否则他第一次操作就会悄悄打乱 lock 顺序 - CI 中加
composer install --dry-run校验：失败说明有人改了composer.json却没提交新composer.lock，立即阻断合并 - 功能分支完成依赖变更后，应尽快合入
main，避免多人长期并行修改依赖，放大冲突概率
