用 JavaScript 对 JSON 进行模式匹配 (Part 2 - 实现)
这篇续作紧接着上一篇的接口设计，直接深入到 `Dispatcher` 类的具体实现。作者展示了如何将一个为 JSON 模式匹配设计的抽象接口，用 JavaScript 代码一步步落地。 核心思路在于递归遍历模式对象和目标 JSON。作者利用 `Object.entries` 遍历模式的键值对，并通过 `typeof` 检查值的类型来区分处理逻辑：对于基本类型直接比对；对于对象或数组则递归进入下一层。巧妙之处在于，代码利用了 JavaScript 动态类型的特性，让模式本身能非常灵活地描述待匹配数据的结构。 文章不仅展示了完整的实现代码，还解释了处理“可选属性”和“未知属性”等细节时的考量。这种从设计到实现的完整闭环，对于想学习如何构建自己的模式匹配工具，或是深入理解 JavaScript 对象操作的开发者来说，提供了清晰的参考路径。
用 JavaScript 对 JSON 进行模式匹配 (Part 1 - 设计)
这篇讲的是在JavaScript中如何用JSON实现模式匹配，来解决分支逻辑日益臃肿的现实问题。 作者从一个常见痛点出发：当代码里充斥着大量if-else或switch-case时，逻辑会变得难以维护。他回顾了之前的思路，即通过构建一个专门的“调度器（dispatcher）”来筛选和转发请求，从而对复杂分支进行抽象。而如何优雅地描述筛选条件，就成了关键。 文章提出，JSON正是描述这类模式的理想选择——它结构清晰、易于编写和解析。作者计划基于此思路，打造一个实用的JSON模式匹配工具。本文作为系列的第一篇，重点梳理了这个工具的设计哲学与核心架构，为后续的代码实现打下基础。
为什么 script 标签不能写成自关闭形式
这篇讲的是很多前端开发者都可能在代码审查中遇到的疑问：为什么 `` 这种简洁的自关闭写法虽然在现代浏览器里不报错，却始终不被推荐，甚至可能埋下隐患。 文章从 HTML5 的容错解析机制入手，对比了其与 XHTML 严格解析模式的根本差异。核心在于，浏览器在遇到 `` 时，为了向后兼容，不会将其视为一个完整的自闭合标签，而是会继续在文档后续内容中寻找一个配对的 `` 结束标签。这个看似微小的解析行为差异，可能导致脚本内容被意外“吞掉”而不执行，或是引发后续页面结构解析的连锁错误。 作者通过具体的解析流程分析，将规范要求背后的技术原理讲得很透彻。它不仅仅是在说“不要这么写”，更解释了“为什么不能这么写”，帮助读者建立起对 HTML 解析模型的深层理解，从而在编码时能做出更规范、更稳健的选择。
在 JavaScript 中监听 IME 键盘输入事件
这篇技术博客聚焦于 JavaScript 开发中一个隐蔽却棘手的坑：输入法（IME）如何干扰键盘事件监听。作者从实际项目中的 Suggestion 控件需求出发，描述了当用户启用输入法时，键盘事件的触发变得异常复杂——不同操作系统和浏览器可能在每次击键、选词完成或整句输入时才触发事件，最极端情况下甚至只响应一次 keydown，后续事件完全消失。 问题的根源在于跨平台兼容性缺失，事件监听机制无法统一处理 IME 输入。这导致依赖实时文本变化的控件面临困境：事件监听本是最精确、最节省资源的方案，但 IME 引发的事件遗漏迫使开发者考虑轮询检测，而轮询会显著增加计算负载，影响应用性能。文章通过具体场景剖析，点明了这一技术点中的痛点。
从 if else 到 switch case 再到抽象
这篇讲的是代码中复杂分支的抽象之道。作者从接手遗留代码时常遇到的痛点切入——那些嵌套两层以上的 if-else 或 switch-case 往往让人望而生畏。文章指出，这类复杂分支并非天生，而是在需求迭代中，因开发者追求短期速度或抽象意识不足，不断用标志位和条件判断“打补丁”累积而成。 作者以一段百度Hi老代码为例，揭示了复杂分支的核心问题：一个简单的 else 分支，其实隐含了它前面所有条件取反再相与的复杂逻辑，这使得代码意图变得极其隐晦，难以阅读和维护。 为了解决这一问题，文章提出了两种清晰的抽象路径。一是用面向对象的工厂模式，将不同分支的处理封装到独立的类中，解除嵌套，让每个模块只需关注自身职责。二是采用声明式的模式匹配，用直观的数据结构描述直接匹配目标数据，彻底消除隐含逻辑。后者让每个监听条件都明确、独立，大大提升了代码的可读性。文章最终引导读者思考，如何通过提升抽象层次，让代码在复杂迭代中保持清晰。
程序员的品味
这篇讲的是作者从一次《程序员》杂志内容讨论会出发的思考。席间，大家激烈探讨了杂志的走向，这引发了作者对程序员群体“品味”的深层反思——这种品味，或许不仅关乎代码的优雅或架构的选择，更关乎我们如何理解技术、产品与人之间的复杂联结。文章并未给出标准答案，而是坦诚地记录了这种思考的过程与张力，尤其是那种想要梳理清楚却又暂时难以落笔的困惑状态。 作者试图探讨的是，在快速迭代的技术世界里，程序员应当如何培养和坚守自己的判断力。这可能超越纯粹的技术层面，延伸到对工具、流程乃至行业现象的审美与抉择。文中流露出的观点，对于那些不满足于仅做“实现者”，而希望成长为有独立见解的“创造者”的开发者来说，提供了一种内省的视角，提醒我们技术能力之外的另一种核心素养。
Apple 谈论产品 vs Microsoft 谈论技术
这篇讲的是技术社区里一个经典争论的根源。作者从 Jeff 的一篇博文出发，回顾了 Twitter 上关于 Apple 与 Microsoft 开发者文化的一场激烈讨论。 文章的核心发现是：许多争论之所以无解，并非技术本身，而是双方底层的“观点框架”不同。Apple 的视角更多聚焦于产品体验与人文设计，技术是达成优雅产品的工具；而 Microsoft 的视角则深耕技术细节、平台能力与开发者生态，技术本身就是价值核心。长期使用微软技术的开发者，很容易在微软密集的宣传下，自然地接纳并内化后者的技术观。 问题在于，人们常常用自己内化的“微软观点”去评判“苹果观点”，比如质疑后者的开放性或技术深度，这就像拿着锤子去衡量螺丝刀是否好用，必然会产生隔阂与误解。这篇文章提醒我们，理解技术争论时，或许先要识别双方站位的“价值观地基”是否一致。
程序之外的事情 (Part 1 - Speech)
这篇讨论从程序员公众表达能力的争议切入。作者开篇提到近期热文《程序员需要培养企业家式的能力》，该文认为程序员普遍存在公众讲话会脸红、不善表现自己的问题。但作者对此观察提出质疑——在他熟悉的程序员圈子里，情况恰恰相反，他遇到的许多程序员都善于交流，并能通过对话激发有趣的创意与观点。 文章的核心在于这一基于个人经验的发现：程序员的刻板印象或许并不普遍成立，许多技术从业者实际上拥有良好的沟通能力。作者推测，这可能与各自所处的圈子和接触的群体有关，他所认识的程序员恰好都是沟通意愿和能力较强的一类。 这个观察揭示了技术社区中的多样性，提醒我们不应被单一的标签所局限。它引导读者思考：在埋头技术之外，开放的交流与表达同样是构建技术影响力、激发创新的重要维度。
控制浏览器是否缓存网页状态
这篇讲的是如何精确控制浏览器对网页的缓存行为。作者从一个常见的前端开发痛点切入——明明修改了代码，但浏览器总显示旧页面，导致调试困难或用户更新体验差。 文章的核心方案是利用HTTP头字段`Cache-Control`和`Expires`。作者清晰地拆解了各种指令的含义，比如`no-store`是完全禁止缓存，`must-revalidate`则要求每次使用前必须向服务器确认。这些字段的组合能应对多种场景：开发阶段可以强制不缓存以方便调试；上线后则可设置为长期缓存静态资源，同时让HTML入口文件短时缓存或每次校验，从而实现高效更新。 特别巧妙的一点是，文章不仅讲了基本配置，还深入到了不同状态码（如304 Not Modified）与缓存策略的配合，以及`max-age`与`Expires`的时间计算差异。这帮助开发者理解，缓存控制不仅仅是“存或不存”的二元选择，而是一个可以精细调控的完整生命周期管理。