技术博客
Sublime Text 不会自动把 CMakeLists.txt 当作 CMake 语法处理，它默认按纯文本或“Plain Text”解析——所以关键词没颜色、缩进乱、函数名不突出。根本原因是：Sublime 的语法识别靠文件扩展名和首行 shebang 或内容特征匹配，而 CMakeLists.txt 既无扩展名标识（不是 .cmake），首行又通常为空或注释，触发不了 CMake 语法包。
Composer 默认把依赖装进项目根目录下的 vendor 文件夹，改它最直接。在项目根目录的 composer.json 里加一段配置就行：
发布时追求小体积，-Os 是最直接有效的编译选项——它在优化运行速度和代码大小之间倾向后者，会主动内联更保守、避免生成冗余指令序列。而 -O2 和 -O3 默认优先保性能，常导致函数内联过度、模板实例膨胀、甚至插入额外的运行时检查代码。
默认情况下，composer 的网络请求超时是 300 秒（5 分钟），但实际遇到慢源（比如国内直连 packagist.org）、代理不稳定或大包下载时，经常在 Downloading… 阶段卡死，最终抛出类似 Connection timed out 或 cURL error 28: Operation timed out 的错误。
离线源本质是把 packagist.org 的元数据镜像到本地或内网服务器，让 composer install 不依赖外网。不是简单改个 repositories 就能生效——Composer 默认仍会 fallback 到官方源，除非显式禁用。
浏览器缓存 CSS 文件时，只看 URL 是否完全一致。哪怕文件内容变了，只要 URL 没变，就可能复用旧缓存。v=1.0.0 这种查询参数本质是 URL 的一部分，改了它，浏览器就当它是新资源重新请求。
因为 std::function 带运行时开销，且无法推导重载函数、函数模板或临时 lambda 的完整类型。泛型算法依赖编译期类型推导来适配任意可调用对象，而 std::function 会擦除类型信息，导致无法匹配重载、丢失 constexpr 能力，甚至让 SFINAE 失效。
直接运行 composer init 会进入交互式问答流程，填完项目名、描述、作者、依赖等十几项才能生成 composer.json。实际开发中，90% 的初始项目只需要最小可用配置——比如一个空的 composer.json 或仅声明 PHP 版本约束。
Composer 不处理 PSR-4 映射，它只读取并执行你写的 autoload 配置；映射是否生效，取决于你写的路径对不对、文件结构符不符合 PSR-4 规则。
它不是 C++ 标准类型，而是 POSIX 定义的带符号整型，专用于表示“可正可负的字节数”，比如 read()、write()、recv() 的返回值。用 int 接收这些函数返回值是常见错误——在 64 位系统上，ssize_t 通常是 long int（8 字节），而 int 仍是 4 字节，截断会导致负值误判为大正数，比如 -1 变成 4294967295。