Composer装完不等于跑通，需在CLI/Web/Docker等环境均能稳定加载类；PHP≥8.0且openssl/zlib/json/mbstring四扩展缺一不可；入口文件必须用__DIR__ . '/vendor/autoload.php'引入；install只读lock，update重算依赖树；国内应优先切换阿里云镜像。
composer 不是装完就能跑通的工具，它对 PHP 环境、路径、权限和网络极其敏感。第一次执行 composer install 成功，不等于你已上手；只有在不同环境（CLI/Web/Docker）下都能稳定加载类、不报 Class not found、不因镜像或 lock 文件错乱导致行为突变，才算真正踩稳了第一步。
PHP 版本与扩展必须提前验证，别等 composer install 报错才查
Composer 2.5+ 要求 PHP ≥ 8.0，但很多教程只写“PHP 7.3+”，容易误导。实际运行中，版本不匹配会表现为：
-
Could not open input file: composer.phar—— 表面是路径问题，实则是 PHP 解析器不兼容 -
Failed to decode response—— 常因缺少openssl或zlib扩展，导致无法解密/解压包 - Windows 下用 Git Bash 运行
php composer.phar失败 —— 路径格式被转成/c/Users/xxx，autoload 加载失败
验证命令必须按顺序执行：
php -v # 看是否含 "NTS"（非线程安全），且 ≥ 8.0<br>php -m | grep -E "(openssl|zlib|json|mbstring)" # 四个扩展缺一不可<br>where php # Windows 确认 PATH 指向正确的 php.exe
vendor/autoload.php 必须用 __DIR__ 引入，相对路径是定时炸弹
写 require 'vendor/autoload.php'; 看似没问题，但只要换一种调用方式（比如 CLI 执行 php cli.php、Nginx 配置了别名路径、或入口文件被 include 到其他目录），就会立刻触发 Class not found。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 错误写法：
require './vendor/autoload.php';、require '../vendor/autoload.php';、require 'vendor/autoload.php'; - 正确写法：
require __DIR__ . '/vendor/autoload.php';——__DIR__是当前文件所在目录的绝对路径，不随执行上下文变化 - 所有入口文件（
index.php、cli.php、phpunit启动脚本）第一行都必须是这行，且不能有任何输出或 session 操作在它之前
composer install 和 composer update 不能混用，lock 文件是信任锚点
团队协作中最隐蔽的问题，往往来自有人偷偷运行了 composer update 并提交了新 composer.lock。其他人 install 后发现行为异常，却查不出原因。
-
composer install：只读composer.lock，安装完全一致的依赖树 —— 适用于git clone新项目、CI/CD 构建、线上部署 -
composer update：忽略lock，重新解析composer.json，拉取满足约束的最新兼容版 —— 仅用于本地开发加依赖或主动升级 - 加包必须用
composer require monolog/monolog（它内部自动update并更新lock），不要手动改composer.json后裸跑update - 删掉
vendor和composer.lock只留composer.json就跑update，等于放弃版本控制，极易引入破坏性变更
国内网络下卡在 Loading composer repositories？先换源再排查
这不是 Composer 坏了，也不是你断网了，而是默认访问 https://packagist.org 被阻断。现象是长时间无响应，-vvv 会卡在 Downloading https://packagist.org/packages.json。
- 优先用阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 如果提示
Permission denied，说明全局配置目录权限不对，先运行：sudo chown -R $USER:$USER $(composer config -g home) - 项目级覆盖（如老项目必须用原源）：在项目根目录
composer.json中加："repositories": {"packagist": false}，再单独配私有源 - 别用已停服的旧镜像地址（如
https://packagist.phpcomposer.com），它们会返回 404 或空响应
真正的坑不在命令怎么敲，而在于你以为“能跑就行”时，已经埋下了跨环境不一致、上线崩溃、安全校验失效的伏笔。尤其当 vendor/autoload.php 的路径写错、composer.lock 被悄悄更新、或镜像配置被项目级设置覆盖——这些地方不会报错，只会让问题延迟到最意想不到的时刻爆发。
