技术博客
只有当项目中类文件数量多（比如 >1000 个）、且使用了 psr-0 或 psr-4 以外的自动加载方式（如 classmap），或者你明确观察到 composer/autoload_classmap.php 文件体积过大、类加载变慢时，才值得启用优化。现代 Composer（2.0+）默认已启用 –apcu 和更高效的生成策略，–optimize 实际上已被弃用 —— 它在 Composer 2.2+ 中完全移除，运行会报错：Unknown option: –optimize。
WSL2 的 /mnt/c 是通过 DrvFs 挂载的 Windows NTFS 分区，所有文件操作都要跨内核桥接，composer install 时大量小文件读写（比如 vendor 解压、autoloader 生成）会卡在 I/O 上，实测比原生 Linux 慢 3–5 倍。
Sublime 默认不显示行号，但开启非常简单，关键是别去菜单里翻半天——直接用快捷键最稳。Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS）呼出命令面板，输入 Toggle Line Numbers 回车就行。这个操作是开关式，再按一次就关掉。
脚本钩子必须写在 composer.json 的 scripts 字段下，且顶层键名是预定义的事件名（比如 pre-install-cmd），不是随便起的。Composer 不会执行拼错、大小写不符或未注册的钩子名。
因为 composer 默认不自动生成或安装 shell 补全脚本——它只提供生成能力，且仅限于当前项目根目录下的 composer 命令（即 php composer.phar 或全局安装的二进制），不自动写入系统级补全路径。
因为 composer 本身是 PHP 工具，它依赖宿主机的 PHP 运行时、扩展、CA 证书、网络代理设置，甚至 ~/.composer/ 缓存路径。Docker 容器里如果只简单 apt install composer，大概率遇到：无法加载 openssl 扩展、curl 报 SSL certificate problem、composer install 卡在 Updating dependencies、或者安装的包权限错误导致 Laravel 项目启动失败。
Sublime Text 本身不带“JSON 键转数组”按钮，但靠自带的正则查找替换就能一步到位。关键不是写新插件，而是找准键名在 JSON 中的文本模式。
低带宽下 composer install 卡住，本质是默认的并发数（2）和重试次数（3）不适合弱网——它会反复超时、阻塞、重连，反而拖慢整体进度。不是网络不行，是策略太“刚”。
服务进程（比如用 systemd 或 supervisord 管理的后台服务）默认会把子进程设为同一进程组，脚本一启动就被父服务收编，服务重启/停止时连带干掉——这不是脚本写得有问题，是进程生命周期没切开。
因为默认行为会访问 packagist.org（或你配置的仓库）拉取包元数据、下载 ZIP 或通过 Git 克隆，同时还会校验 composer.lock 中记录的 dist URLs 和 commit hash。只要 DNS、HTTPS 连接或证书验证任一环节断开，就会报 Could not fetch、failed to open stream 或 SSL certificate problem。