laravel命令找不到是因为Composer全局bin目录未加入PATH环境变量，需手动将~/.composer/vendor/bin（Linux/macOS）或%APPDATA%\Composer\vendor\bin（Windows）添加至PATH并重载配置。
全局安装的命令找不到，不是没装成，是系统根本没去那个目录找
执行 composer global require laravel/installer 成功后，laravel 命令仍报 command not found，90% 的情况是因为 Composer 把可执行文件放到了 ~/.composer/vendor/bin（Linux/macOS）或 %APPDATA%\Composer\vendor\bin（Windows），而这个路径压根不在你的 $PATH 里。
这不是 Composer 的 bug，是它故意把工具二进制和项目隔离的结果。系统 shell 只认 $PATH 里的路径，其他地方一概无视。
- Linux/macOS：往
~/.zshrc或~/.bashrc末尾加export PATH="$HOME/.composer/vendor/bin:$PATH"，再运行source ~/.zshrc - Windows：在「系统属性 → 高级 → 环境变量」中，把
%APPDATA%\Composer\vendor\bin加进「用户变量」的PATH，然后必须新建一个终端窗口（关掉再开不算） - 验证方式：
echo $PATH或echo %PATH%看输出里有没有对应路径；再试which laravel或where laravel
项目里装了 phpunit，为什么不能直接敲 phpunit？
composer require phpunit/phpunit 装完后，phpunit 命令不可用，不是失败，是设计如此——它的可执行文件只存在于当前项目的 vendor/bin/phpunit，没进 PATH，shell 自然找不到。
强行把项目 vendor/bin 加进全局 PATH 或手动建软链，等于破坏项目边界。CI 流水线会挂，同事拉代码也跑不起来。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 推荐做法：在
composer.json的scripts字段里加一条"test": "php vendor/bin/phpunit"，之后统一用composer test - 临时调用：Linux/macOS 执行
./vendor/bin/phpunit，Windows 执行vendor\bin\phpunit - 别用
phpunit直接调用，除非你确认当前$PATH左侧优先匹配的是本项目路径（容易误调旧版本）
哪些该全局装，哪些死都不能全局装？
判断标准不是“是不是命令行工具”，而是“它参不参与项目运行逻辑”。一句话：工具装全局，依赖装项目。
- ✅ 推荐全局：
laravel/installer、friendsofphp/php-cs-fixer、phpstan/phpstan—— 它们只在你敲命令时起作用，不被autoload加载，不上生产环境 - ✅ 必须项目内：
guzzlehttp/guzzle、monolog/monolog、symfony/console—— 会被代码new或use，必须写进composer.json，必须进composer.lock，必须上生产 - ⚠️ 特别注意：
phpunit/phpunit表面是工具，但常被phpunit.xml或tests/bootstrap.php显式引用，CI 也依赖具体版本，所以更推荐项目内装 - ❌ 绝对禁止全局：
doctrine/dbal、laravel/framework—— 全局装了等于让composer.lock失效，部署时类找不到、版本错乱、错误指向你根本没装过的类
全局和项目都装了同一个包，为什么报 Class 'Symfony\Component\Console\Application'？
这不是 Composer 配置错了，是 autoload 冲突的典型表现：全局和项目各自加载了不同版本的 symfony/console，而 Composer 的自动加载器按注册顺序搜索类，一旦先加载了旧版，新版里的类就永远找不到。
比如全局装了 php-cs-fixer v3.12（带 symfony/console v5.4），而项目用了 v6.3，两个 Application 类冲突，报错就发生在 bin 脚本启动时。
- 根本原因：全局 bin 目录在
$PATH中靠前，shell 优先执行了全局版本 - 临时绕过：用完整路径调用，如
./vendor/bin/php-cs-fixer - 长期解法：避免全局和项目共存同一工具；若必须共存，确保它们依赖的底层组件（如
symfony/console）版本兼容，否则就得删掉全局版本
