PSR-4映射必须在扩展包自身的composer.json中配置，不能依赖项目根目录；需正确声明autoload字段、确保src目录结构与命名空间严格匹配、类名文件名大小写一致，并执行composer dump-autoload注册自动加载。
psr-4映射必须写在包自己的composer.json里
本地扩展包的自动加载不依赖项目根目录配置，而是由包自身声明。你写的MyCompanyUtils命名空间，必须在包根目录的composer.json中用"autoload"字段配好，不能指望项目去“替你加”。常见错误是只改了项目composer.json的repositories，却忘了给包本身配autoload。
正确写法示例（包内composer.json）：
{
"name": "mycompany/utils",
"autoload": {
"psr-4": {
"MyCompany\Utils\": "src/"
}
}
}
-
MyCompany\Utils\末尾双反斜杠是JSON转义，PHP最终看到的是MyCompanyUtils，缺一不可 -
src/路径必须存在，且目录结构要严格匹配命名空间层级：比如MyCompanyUtilsHelper对应src/Helper.php - 类名和文件名大小写必须完全一致，
Helper.php≠helper.php，Linux下直接失败
装完包后必须手动执行composer dump-autoload
即使composer require mycompany/utils:dev-main成功，类也不会自动可用——因为Composer只负责把包软链进vendor/，自动加载器仍需重新注册映射。漏掉这步，Class not found是必然结果。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer dump-autoload（开发阶段别加-o），让新包的psr-4规则写入vendor/composer/autoload_psr4.php - 如果包还提供了测试类，且你把它放在
autoload-dev里，得额外跑composer dump-autoload --dev - CI环境尤其要注意：有些流水线脚本只跑
composer install，但没加dump-autoload，导致构建通过、运行报错
classmap或files用于兜底老代码或函数文件
如果你的扩展包里混着无命名空间的老类（比如legacy/Database.php）或全局函数文件（如helpers.php），别硬塞进psr-4。它们需要单独处理：
- 老类用
classmap：在包的composer.json中加"classmap": ["legacy/"]，Composer会扫描所有.php文件并提取class声明 - 函数文件用
files：写"files": ["helpers.php"]，它会在vendor/autoload.php加载时被require_once一次 -
classmap和files都要求路径相对于包根目录，不能用../或绝对路径
Windows下path仓库容易因符号链接失效
Windows对path类型仓库的支持比Linux/macOS弱，尤其是启用WSL或Git Bash时，软链接行为不一致。表现是vendor/mycompany/utils看起来存在，但实际是空目录或硬拷贝，导致dump-autoload找不到包内的autoload配置。
- 验证是否真软链：
dir vendormycompanyutils，若显示<SYMLINKD>才对；否则说明repositories没生效 - 确保本地包目录已
git init且有至少一个commit，否则Composer在Windows下可能静默跳过 - 路径写
"url": "./packages/my-utils"，别用file://或C:xxx，也别用~/
最常被忽略的一点：包的autoload配置和项目是否用path仓库完全无关。哪怕你删掉repositories，只要包已安装进vendor，它的autoload就仍起作用——前提是当初装的时候，它的composer.json里真写了正确的映射。
