配置 Nginx 子域名的泛解析
这篇文章讲的是如何配置 Nginx 实现子域名的泛解析，让所有形如 `sub.domain.com` 的子域名请求都能被正确处理。作者从实际需求出发：希望在不破坏主域名（`domain.com` 和 `www.domain.com`）访问的前提下，让不同的子域名自动映射到服务器上对应的目录（例如 `sub` 映射到 `www-sub` 目录）。 核心方案十分巧妙：在 Nginx 配置的 `server_name` 指令中直接使用通配符 `*.domain.com` 来承接所有子域名请求。然后，通过一个正则表达式动态提取主机名中的子域名部分，并将其存入变量 `$subdomain`。最终，在 `root` 路径的定义中拼接这个变量，例如 `root /home/user/www$subdomain/;`。这样一来，访问 `blog.domain.com` 时，网站根目录就会自动指向 `/home/user/www-blog/`。 这个方案的亮点在于“动态路径映射”，避免了为每一个子域名单独编写 `server` 块的繁琐配置。作者也特意说明了正则中排除 `www` 的逻辑，确保主域名配置不受干扰。整体思路简洁高效，对于需要管理大量子域名的开发者来说，是一个非常实用的配置模板。
Git subtree 要不要使用 –squash 参数
这篇讲的是，作者在使用 Git subtree 管理多层代码包含关系时，遇到了一个持续困扰的冲突问题，并深入分析了 --squash 参数背后的机制与应对策略。 作者从实际项目（Gregarius 管理 MagpieRSS，后者又管理 Snoopy）出发，指出使用 subtree 的 --squash 参数虽然能让主项目提交历史更清爽，却会在后续更新（subtree pull）时，反复引发需要手动解决的冲突。反之，不用 --squash 虽然更新顺畅，但子项目的历史会“污染”主项目。 文章清晰地剖析了根因：--squash 会合并并消除子项目的历史提交，导致下次合并时 Git 找不到共同的父提交，从而无法自动处理冲突。作者引用并评估了 StackOverflow 上的一种平衡方案：在一个专用分支上进行不带 --squash 的更新以保留历史、避免冲突，然后在合并到主分支时使用 `git merge --squash` 将其压缩为一个简洁的提交。 文章最后总结了两种典型的使用场景：如果只是单向接收子项目更新，任选一种方式均可；如果是拆分大项目（如 Symfony2），则建议避免 squash，主项目主导开发再 split 出子项目发布。作者的实践表明，专用分支方案虽然略增复杂度，但能有效兼顾提交历史的整洁与更新的顺畅。
防火墙的目标地址转换和源地址转换
作者从一起防火墙故障出发，探讨了目标地址转换与源地址转换的配置逻辑。故障表现为外网用户能成功发送请求到内网网站，却始终收不到响应。排查发现，根源在于内网服务器配置了两块同网段网卡且均设置了网关，导致返回数据包的源地址与请求进入时的目标地址不一致，防火墙因此无法将响应数据正确关联到原有会话。 要解决这一问题，需要理解防火墙的数据包处理流程。在常规的“外网访问内网”场景中，通常只需配置目标地址转换。但在上述网卡配置错误的特殊情况下，必须同时配置源地址转换，强制让内网服务器的返回流量经过防火墙，从而维持会话的对应关系。同样，当“内网通过域名访问另一内网服务器”时，源地址转换也是必需的，它避免了内网主机间直接通信导致防火墙无法跟踪连接状态的问题。 文章通过实例拆解了两种地址转换在不同场景下的必要性，核心在于确保返回数据包的路由路径能被防火墙正确识别和管理。作者最后指出，虽然具体防火墙机制各异，但基本原理相通：在规划地址转换时，必须考虑数据包返回的路径，否则可能导致通信失败或应用获取不到真实客户端IP。
在移动硬盘上安装 Arch Linux
这篇讲的是作者如何在移动硬盘上搭建一个便携的 Arch Linux 学习环境。起因是厌倦了 Ubuntu 半年一次的大版本升级，同时希望深入接触滚动更新的发行版。为了不影响主力工作机，作者选择将系统安装在移动硬盘上，以便随时折腾和学习。 文章详细记录了从分区规划到系统配置的全过程。作者为这块硬盘设计了四个分区：10G 的 btrfs 分区安装 Arch 系统本身，10G 的 ext4 分区用作用户主目录，一个大容量 NTFS 分区用于日常数据交换，以及小容量的交换分区。安装过程中，他特别注意了针对移动存储设备的优化，比如在 fstab 中启用 relatime 和 discard 参数，将 /tmp 挂载到内存，并通过调整 swappiness 参数尽量减少对磁盘的写入，以保护硬盘寿命。 除了基础系统安装，文章也涵盖了引导配置、时区语言设置等初始工作。整个过程不仅是技术步骤的罗列，更分享了作者从 Ubuntu 转向 Arch 的心路历程，以及他对服务器环境稳定性的谨慎态度。对于想尝试新发行版又担心影响现有系统的读者来说，这提供了一个清晰的、可复现的实践路径。
Git commit 注释格式
这篇技术文章从一个常见但容易被忽视的细节入手：Git commit的注释格式。作者指出，虽然Git没有硬性规定，但良好的注释习惯对团队协作和项目历史维护至关重要。 文章以Linux内核、PHP等知名开源项目的实践为例，总结了一套推荐的注释规范。核心是“50/72”规则：首行总结不超过50字符且不使用句号，空行后接不超过72字符宽度的详细说明。这种结构既让`git log`输出更清晰，也方便用于邮件通知的标题与正文分离。 除了格式，文章还着重指出了应当避免的“坏味道”提交，比如将版本控制工具当作临时备份、把不相关的修改混在一次提交里，或是用“修正错误”这样含糊的描述。同时，它也提供了一些实用技巧，例如使用`module:`前缀组织大项目提交，以及用`git diff --check`预检空白字符错误。 这篇文章没有空谈理论，而是直接给出了可操作的标准和反面案例，帮助开发者快速建立专业的提交习惯。
WordPress 烦人的 revision 和 auto-draft
这篇讲的是WordPress里两个让人头疼的功能：revision和auto-draft。作者发现revision由来已久，auto-draft则是最近才注意到，两者共同的问题在于——它们会在后台默默占用资源和数据库空间，却偏偏没有提供显式的关闭选项。这种“强制启用”的设计让许多注重网站整洁的管理员感到困扰。 文章没有停留在抱怨，而是具体点出了功能的机制：每次编辑都可能生成版本记录和自动草稿，长期累积下来可能拖慢站点效率。作者以个人体验出发，道出了不少用户的心声：明明用不到，又关不掉，只能手动清理或依赖插件补救。 对于正在管理WordPress站点的读者来说，这篇文章提醒了大家关注那些被系统默认开启却未必需要的功能。它或许能促使你检查一下后台那些沉默的“数据膨胀”源头，思考如何在不影响核心体验的前提下保持站点的轻量化运行。
可恶，被 PHP-Mcrypt 的官方 Example 误导了
作者在为项目寻找轻量级的PHP对称加密方案时，采用了官方mcrypt模块的示例代码，却遇到了加密数据无法正确解密的诡异问题。深入排查后，他发现根源在于官方Example本身的一个关键疏漏：示例没有明确指定字符串与密钥的字符编码。 核心症结在于，PHP内部的字符串处理依赖于字符编码。当加密与解密过程编码不一致（例如，示例中可能混用了UTF-8与ISO-8859-1），就会导致加密后的数据在解密时因编码不匹配而彻底损坏。作者最终发现，显式统一使用UTF-8编码进行加密与解密，问题迎刃而解。 这个案例提醒开发者，在处理加密时，不仅要关注算法本身，更要对数据的“表示形式”（如字符编码）保持高度警惕。官方文档的示例有时为了简洁可能会忽略这类前提条件，在实际生产环境中直接照搬，很可能就会掉进类似的陷阱。