新项目用 composer install 精确还原依赖；update 会重算依赖树，仅用于主动升级指定包或 ci 上线前统一更新。

composer install 和 composer update 到底该用哪个

新项目拉下来直接跑 composer install，别手贱敲 composer update——后者会无视 composer.lock 重算依赖树，很可能升级到不兼容的版本，Laravel 9 项目里升个 symfony/console 到 v7 就可能让 php artisan 直接报错。

只有明确要升级某个包（比如修一个已知 bug），才局部更新：composer update monolog/monolog。全局 update 应该是上线前在 CI 环境做，且必须确认 composer.lock 已提交。

• install：读 composer.lock 精确还原依赖，开发协作和部署时的唯一安全操作
• update：重新解析 composer.json，生成新 lock 文件，仅用于主动升级
• CI/CD 流水线里必须用 install，否则每次构建都可能因依赖漂移失败

Laravel 项目里 vendor/autoload.php 怎么被加载的

不是靠你手动 require，而是 Laravel 的入口文件 public/index.php 第一行就写了：require __DIR__.'/../vendor/autoload.php';。这个文件由 Composer 自动生成，它把所有 PSR-4 映射、类映射、autoload-files 全部注册进 PHP 的自动加载机制。

所以你加了个新服务提供者，或者改了 composer.json 里的 autoload 配置，必须运行 composer dump-autoload 才生效——否则 App\Providers\CustomProvider 类明明存在，PHP 还是报 Class not found。

• 修改 autoload 段（如加 psr-4 映射）后，必跑 composer dump-autoload -o（-o 启用优化，生成 class-map 加速加载）
• 新增了 files 类型的全局函数（比如 app/Helpers/functions.php），也要 dump-autoload，否则函数不可用
• dump-autoload 不会重装包，只刷新自动加载逻辑，比 install/update 快得多

为什么 composer require laravel/sanctum 报错“package not found”

大概率是你没切对源，国内环境默认走 Packagist 官方源（https://packagist.org），但有些包（尤其是刚发版的 Laravel 官方扩展）在镜像站同步有延迟，或者你本地配置了过期的私有源。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

先执行 composer config -g repo.packagist 看当前全局源；再用 composer config -g repo.packagist https://packagist.org 强制切回官方源试试。如果还是不行，加 -vvv 参数看详细错误：composer require laravel/sanctum -vvv，常能看到 404 或 DNS 解析失败这类底层问题。

• 国内建议用阿里云镜像：composer config -g repo.packagist https://mirrors.aliyun.com/composer/
• 某些企业内网禁外网，得配私有源，这时 require 前得先 composer config repositories.xxx 添加对应源
• 报错含 could not find package 但包名没错，基本就是源的问题，不是包不存在

composer.lock 被改了但没提交，会出什么问题

别人 git pull 后跑 composer install，结果装出来的依赖跟你本地不一样——因为 lock 文件没同步，Composer 只能按自己机器上的 lock（可能是旧的或空的）去装，轻则功能异常，重则 artisan migrate 因数据库迁移类版本不一致直接崩溃。

Laravel 项目里 composer.lock 是强制要求提交的文件，它比 composer.json 更关键。CI 构建失败、测试环境和线上行为不一致，八成是因为有人忘了 git add composer.lock。

• 只要 composer.json 改了（哪怕只是加个注释），就必须 composer update 或 install 生成新 lock，然后 git add composer.lock
• 团队里有人 rm composer.lock 再 install，等于悄悄重置了整个依赖快照，这种操作必须同步通知所有人
• GitHub PR 检查里建议加一条：diff 中必须包含 composer.lock 修改，否则 CI 拒绝合并

依赖管理真正的麻烦不在命令怎么敲，而在于谁在什么时候动了 lock 文件、有没有同步到仓库、不同环境是否用了同一份快照——这些细节一漏，问题就藏在深夜三点的线上日志里，还不好复现。