技术博客
启用 prepend-autoloader 后，Composer 会把 vendor/autoload.php 中的自动加载逻辑“插到最前面”，从而让 composer.json 里定义的 autoload-dev 或 autoload（尤其是 psr-4 / classmap）优先于项目根目录下同名类文件被加载——但前提是这些类没被其他 autoloader 先注册过。
autoload 配置错一个字母，composer dump-autoload 不报错，但运行时直接 Class not found。根本原因不是“没加载”，而是 PSR-4 映射路径和命名空间不严格对齐。
PHP 不会自动把当前命名空间“补全”到类名上，哪怕类文件就在同一目录、命名也一致。比如你在 AppControllers 下写了 UserController 类，但没加 namespace AppControllers;，那它实际属于全局命名空间；此时用 new UserController() 能成功，但用 new AppControllersUserController() 就会报错——因为 PHP 找不到那个完整路径下的类。
直接运行 composer show vendor/package 不会输出该包的 autoload 配置——这是常见误解。Composer 的 show 命令只展示包元信息（如版本、描述、依赖），不解析其 composer.json 中的自动加载规则。
跨平台代码里直接调 getpid() 在 Windows 上会链接失败（找不到符号），而硬写 GetCurrentProcessId() 在 Linux/macOS 下根本不存在。这不是“哪个更好”的问题，而是头文件、链接库、ABI 完全隔离的两套机制。
很多人以为只要在 XML 里写上 schemaLocation，解析器就会自动联网下载或按路径读取 XSD 来校验——这是错的。schemaLocation 只是一个提示（hint），它本身不触发任何加载行为。是否使用、如何使用，完全取决于你用的解析器和它的配置方式。
直接写 using 比 typedef 更直观，尤其面对模板时不会绕晕。比如想给 std::vector<int></int> 起个短名叫 IntVec，就这么写：
本文详解 django 中因重复包含同一应用 url 模块导致的 `{% url %}` 模板标签解析错误问题，提供清晰的重构方案与最佳实践，帮助开发者彻底解决 url 命名覆盖、路径错乱等常见痛点。
本文详解 django 多层 url 包含（`include`）中因重复引入同一应用路由导致的 `url` 模板标签解析错误，并提供清晰、可维护的 url 分层设计方案。
Composer 本身不提供“打包”功能，它只是依赖管理器；你要发布的不是 zip 包，而是符合 PSR-4 自动加载规范的 Git 仓库，并通过 Packagist 做元数据索引。关键动作是：写好 composer.json、推到公开 Git 仓库、再提交给 Packagist。