编写一个简单的JavaScript模板引擎
这篇讲的是如何从头实现一个轻量级的前端模板引擎。作者从实际场景出发，指出像 Swig 这样的全功能模板引擎有时对于前端简单的 HTML 片段生成显得有些笨重，由此引出了自己动手造一个的需求。 实现思路清晰而巧妙：核心在于将模板字符串编译成一个可执行的渲染函数。具体来说，是通过正则表达式（`/\\{\\s*([a-zA-Z\\.\\_0-9()]+)\\s*\\}/m`）匹配出模板中的变量占位符（如 `{ user.company }`），然后动态生成一个函数代码字符串。这个生成的函数在运行时，会将 `model` 数据绑定到 `this` 上，通过类似 `this.user.company` 的方式直接访问数据并拼接成最终的 HTML 片段。 其中最巧妙的一点是利用了 JavaScript 的 `new Function()` 机制，将模板字符串“编译”为真正的函数对象。这不仅让渲染过程高效，也天然支持了对复杂嵌套属性（如 `user.addr.zipcode`）的解析。文章最后给出的完整 `Template` 构造函数代码，完整地演示了从正则匹配、代码生成到函数编译的全流程，让读者能清晰地理解一个模板引擎最底层的工作原理。
grep awk 之buffer问题
作者从一个常见的管道命令场景出发，解释了为何当`grep`命令被多级管道串联时，数据不会立即流到下一阶段——比如在`while...done | grep abcd | grep abcd`中，第二条grep似乎没有实时输出。 问题的根源在于，无论是`grep`还是`awk`，它们默认都会对输出进行缓冲（buffer），并非逐行传递。对于`grep`，可以通过添加`--line-buffered`选项来切换为行缓冲模式，让数据即时流出。而`awk`的情况更为棘手，它没有直接的选项来改变这一行为，一个有效的变通方法是在awk的输出语句后执行`system("")`，利用空命令来强制刷新输出缓冲区。 这篇技术笔记精准地指出了管道通信中一个容易被忽略的底层机制，并给出了针对性的、可实操的解决方案。它提醒我们，在处理流式数据时，工具的缓冲策略是一个需要特别注意的细节。
GDB 进行程序调试笔记
这篇笔记详细记录了从零开始使用 GDB 调试 C 程序的全过程。作者以一段包含循环累加的简单 C 代码为例，清晰地展示了调试前的必要准备——必须使用 `gcc -g` 参数编译，将源码信息嵌入二进制文件，这是所有调试操作的基础。 进入 GDB 后，文章没有罗列枯燥的命令列表，而是通过实操讲解了最核心的流程：用 `start` 启动程序，用 `list` 查看源码；在函数调用处，区分了 `next`（单步执行不进入函数）与 `step`（进入函数内部）的不同用途。当进入 `add_range` 函数后，通过 `backtrace` 查看函数调用栈帧，用 `info locals` 和 `print` 命令观察局部变量的状态，甚至演示了如何用 `set var` 在运行时修改变量值。最后，以一个命令表格收尾，汇总了 `bt`、`finish`、`frame` 等高频命令的用途。 它本质上是一份面向初学者的 GDB 速查手册，重点突出了调试过程中“查看”与“干预”程序状态的两大核心能力，对于不熟悉命令行调试的开发者来说，是非常实用的入门参考。
进程和线程关系及区别
这篇讲的是操作系统中进程与线程的基础概念辨析。作者从定义出发，开篇就给出了明确定义：进程是资源分配和调度的独立单位，线程则是CPU调度的基本单位，且线程几乎不拥有系统资源，仅保留运行必需的最小集。 文章的核心在于对比二者的根本差异。关键区别在于资源管理方式：进程拥有独立的地址空间，因此一个进程崩溃不会波及其他，健壮性更高但切换开销大；而同一进程内的线程共享全部内存资源，这提升了并发效率与数据共享的便利性，但一个线程的异常往往会导致整个进程终止。 这种设计上的权衡，直接导向了不同的适用场景。对于需要高并发、共享数据且追求执行效率的任务，多线程是更优的选择。反之，对于需要更强隔离性、运行于多台机器或更看重稳定性的场景，多进程模型则更为可靠。文章最后也点明了线程执行开销小但不利于资源保护，进程则相反的特点。
对象到数字 ID 的映射
这篇讲的是如何用一个高效的数据结构，为对象分配并管理短生命周期的数字 ID。 在像 skynet 这样的并行系统中，直接使用 C 指针来标识服务对象是危险的，容易引发悬垂指针、误释放等问题。因此，通常会用数字 ID 来间接引用。作者提出了一个具体的需求：既要快速映射，又希望尽量不复用已释放的 ID（避免误用），这与操作系统常见的文件句柄复用策略不同。 为了满足这个需求，核心方案是设计一张专门的哈希表。每次分配新 ID 时，在上次值的基础上递增，并检查哈希表中对应位置是否冲突，若冲突则继续递增。这保证了 key 永不冲突，让查询速度最快，且实现相对简洁。 更进一步，作者将这部分实现从 skynet 中抽离出来，做成了一个独立的开源库。文章详细介绍了其提供的 5 个 API（创建、销毁、分配、抓取、释放），并重点说明了为实现线程安全而采用的读写锁策略：对表的修改加写锁，而对 ID 的抓取和释放操作则加读锁，允许并发。这份实现还适配了 Windows 的原子操作。 整体上，这是一个解决特定工程问题的精巧数据结构，其实现思路（如不复用 ID 的哈希策略、引用计数与读写锁结合）对需要管理对象生命周期的系统设计很有参考价值。
php 跨域 form提交 2种方法
这篇讲的是如何解决PHP开发中一个常见但棘手的问题：如何实现跨域的表单数据提交。作者从安全策略限制了直接跨域访问的现实背景出发，提供了两种实用的解决方案。 第一种是纯服务端方案，核心是封装一个基于PHP curl的函数。它模拟了客户端发起POST请求的过程，直接在服务器端完成数据的跨域递交。文章中贴出了具体的函数代码，展示了如何拼接参数、设置curl选项并获取返回值，思路清晰直接。 第二种则是当前更主流的前端+后端配合方案。前端通过引入jquery.form.js插件，用ajaxSubmit方法异步提交表单，从而绕过浏览器的同源策略。关键点在于后端PHP代码需要配合设置`Access-Control-Allow-Origin`响应头，明确允许来自指定域名的跨域请求。文章也贴心地给出了允许所有域名或仅允许特定域名的两种写法示例。 总的来说，文章对比了两种风格的实现路径：一种是服务端“代理转发”的经典思路，另一种是前后端协商、利用现代浏览器CORS机制的方案。开发者可以根据项目的实际环境和技术栈，选择更合适的一种来实现跨域数据提交。
python之logging模块详解
这篇讲的是 Python 标准库中 logging 模块的实战用法。作者从最基础的 `logging.debug`、`logging.warning` 等函数讲起，清晰地梳理了日志级别从 `DEBUG` 到 `CRITICAL` 的大小关系。 文章的核心在于通过具体代码示例，手把手地演示如何配置和使用 logging。内容涵盖了如何利用 `basicConfig` 函数自定义日志输出格式（例如加入时间戳、文件名、行号），以及如何将日志同时输出到屏幕和文件。其中还详细解释了 `format` 参数中各个占位符的含义，非常实用。 进阶部分，文章介绍了日志回滚机制，并借助 `RotatingFileHandler` 实现了按文件大小自动备份。更重要的是，它梳理了 logging 模块中不同的 Handler 类型，比如 `StreamHandler`、`FileHandler` 和各类网络处理器，点明了它们各自的应用场景。最后，文章展示了如何通过 `logging.config` 模块使用配置文件来统一管理复杂的日志策略，提供了从简单脚本到规范项目的完整演进路径。
nginx的SCRIPT_NAME, PATH_INFO多了index.php问题
这篇讲的是nginx配置中一个常见的坑：在设置反向代理后，PHP获取到的`SCRIPT_NAME`和`PATH_INFO`变量不正确，把整个URI路径都带上了。比如访问`/index.php/site/login`时，`SCRIPT_NAME`本应是`index.php`，却拿到了完整的路径字符串。 作者定位到问题出在正则表达式定义的`location`块配置不完整。核心解决思路是，需要将请求的URI明确拆解为“脚本文件名”和“附加路径信息”两部分。通过新增一个专门匹配`.php($|/)`的`location`块，并利用正则捕获组`"^(.+.php)(/.+)"`，就能精准地把`index.php`赋值给`$script`，把后面的`/site/login`赋值给`$path_info`。 最终，通过`fastcgi_param`指令将正确拆解后的值传递给PHP处理，使得`$_SERVER['SCRIPT_NAME']`和`$_SERVER['PATH_INFO']`能获得预期的值，保证了框架路由能正常工作。这个配置方法清晰地展示了如何在nginx层面解决路径解析歧义。
php正则修饰符整理
这篇讲的是PHP正则表达式中那些容易被忽略却至关重要的修饰符。作者从实际开发经验出发，系统梳理了i、m、s、x、e、U等十余个修饰符的功能与适用场景。 文章重点辨析了几个常用修饰符的关键差异：比如`i`忽略大小写、`m`让`^`和`$`能匹配行首行尾、`s`让点号能匹配换行符、`e`则允许对匹配结果执行代码。同时，它也提醒了一些注意事项，例如在启用`m`时`D`修饰符会被忽略。 特别值得关注的是，作者指出了`u`修饰符（强制UTF-8编码）在UTF-8环境中可能引发特定Bug，并给出了相关警告。这些细节是理解PHP正则底层行为的关键。 虽然这些修饰符在日常开发中未必频繁使用，但精准理解它们，能让你在处理复杂文本匹配时写出更简洁、高效的正则表达式。
socket消息流程介绍及其C代码实现
这篇讲的是如何用C语言完整实现一个Linux下的TCP服务器，清晰地展示了socket通信从创建到结束的全过程。作者通过一个具体的程序示例，逐步拆解了socket编程的核心流程：首先创建socket并绑定指定的IP与端口，其中还设置了SO_REUSEADDR选项来处理端口复用；接着启动监听，循环接受客户端连接；最后接收指令、执行操作并返回结果。代码中对每个环节都加入了错误处理和状态反馈，使得流程健壮且逻辑清晰。文末还附上了makefile编译脚本和通过工具测试的运行结果，让读者能直观地看到“发送-接收-响应”的完整交互。对于想要理解底层网络编程细节的开发者来说，这篇从代码到理论再到实践的梳理，提供了一个非常扎实的参考范例。
java中文乱码解决之道（八）—–解决URL中文乱码问题
你是否在Java开发中，被URL传递中文参数时出现的“问号”乱码困扰过？这篇文章专门拆解这个棘手问题。作者指出，相比于表单提交，URL编码因涉及浏览器、操作系统和字符集等多种因素，情况更为复杂。核心解决思路是**主动控制编码**，避免浏览器“自由发挥”。 文章主要提供了两种实战方案。一是通过JavaScript前端编码，使用 `encodeURI` 等方法在请求发出前就对中文进行标准化处理，文章还详细对比了一次转码和二次转码在Java后台的解码方式差异。二是在服务端使用Filter过滤器，无论是直接设置请求编码格式，还是在过滤器中自动完成反编码并重新封装请求，都能有效拦截和处理乱码。每种方案都附有具体代码和配置示例，可直接复用。 无论你是正在排查此类问题，还是想从源头建立规范，文中这些经过验证的方法，能帮你一劳永逸地搞定URL中文乱码。
java中文乱码解决之道（七）—–JSP页面编码过程
这篇讲的是JSP页面开发中那个让人头疼的中文乱码问题，尤其是根源常常藏在JSP转换为Servlet的编码过程里。作者直接拆解了关键指令页中的两个编码参数：`pageEncoding`（JSP文件本身的编码）和`contentType`的`charset`（发送给客户端的编码）。 文章核心梳理了转换过程的三次编码“变阵”：第一次JVM编译.jsp文件时，会依据`pageEncoding`或默认编码来读取源码；第二次生成.class文件时，所有内容都被统一转换成Unicode，之前的编码设置在此阶段无效；第三次业务处理后输出到浏览器，则由`contentType`的`charset`决定解码方式，否则会退回默认的ISO-8859-1。 所以，中文乱码的伏笔其实在这几个阶段的配合中早已埋下。搞清楚每个阶段谁说了算，才能在实际开发中精准配置，避免字符“南辕北辙”。
Plack 代码和结构分析-PSGI Application Architecture[译]
这篇文章深入剖析了Perl Web框架Plack的核心架构，重点解读了基于PSGI规范的应用构建方式。作者从PSGI应用的基本定义出发——它本质上是一个接收环境哈希并返回状态、头部、正文三元组的代码块——进而阐明了Plack中最精妙的“洋葱模型”设计。 文中具体展示了中间件如何通过`wrap`方法层层封装核心应用，形成可叠加的处理链。例如，请求会从最外层的中间件C进入，依次经过B、A，最终到达应用核心，响应则反向穿过中间件层返回。这种事件驱动的链式回调结构，使得功能模块（如日志、认证）能以解耦的方式灵活组合。 此外，文章还区分了`Plack::Middleware`和`Plack::Component`的角色，指出后者为创建更复杂的应用组件提供了便捷接口，但核心PSGI应用依然可以保持简洁的代码引用形式。对于想理解Plack如何将简单内核扩展为强大生态的读者，这篇源码级的分析提供了清晰的实现路径。
Plack 代码和结构分析-plackup Architecture[译]
这篇译文深入拆解了 Perl Web 框架 Plack 中 `plackup` 命令的内部架构，核心聚焦于 `Plack::Runner`、`Loader` 与 `Handler` 三者的协作机制。 作者指出，我们常用的 `plackup` 脚本本身只是一个简单的封装，真正的“大脑”是 `Plack::Runner`。它负责解析命令行参数，并依次协调两个关键模块：`Loader` 与 `Handler`。`Loader` 决定了服务器的加载与运行模式，比如是否支持文件更改自动重启（Restarter），或是为每个请求 fork 新进程（Shotgun）。`Handler` 则是一个巧妙的适配层，它通过实现统一的 PSGI 规范接口，使得诸如 Starman、Twiggy 等原生 PSGI 服务器，甚至像 Apache2/FCGI 这类传统服务器，都能被 Plack 框架统一管理与调用。文章特别演示了如何自定义一个 `Handler`，以此扩展框架的服务器支持。 理解这些组件的职责与交互（文中的时序图做了直观总结），对于掌握 Plack 如何以高度可插拔的方式启动和管理 PSGI 应用至关重要，也为开发者自行扩展服务器支持提供了清晰路径。
Plack 代码和结构分析一[译]
这篇讲的是作者从提升源码阅读能力出发，对 Perl 生态中的 Web 框架 Plack 进行的一次深度代码剖析。Plack 本身是 PSGI 规范的工具集，代码以简洁、注释极少且高度自解释而闻名，广泛采用了类似 JavaScript 的回调模式来处理事件驱动。 作者首先通过 Git 获取了项目代码，并统计出它拥有超过 5600 行代码，核心贡献者超过 10 位。为了让庞杂的代码结构化，文章将 Plack 的 lib 目录拆解为三个清晰的层级：负责加载和运行服务器的模块（如 plackup 和 Loader）、用于构建 PSGI 应用的核心组件（如 Builder 和 Middleware），以及支撑测试的模块。每一部分都附有简短的功能描述。 这种从宏观架构到微观目录的梳理方式，把一个看似复杂的框架拆解得层次分明，不仅展示了 Plack 优雅的设计，也为想学习阅读高质量开源代码的开发者提供了一份可操作的路线图。
Plack 代码和结构分析-Plack::Builder[译]
这篇翻译自 kablamo.org 的技术文章，深入拆解了 Perl Web 框架中 `Plack::Builder` 模块的内部实现。作者从其简洁优雅的 DSL 风格配置代码出发，揭示了背后支撑的三个核心编程技巧。 第一个技巧是利用 Perl 的函数原型（`&`），确保 `builder` 块只能接收一个匿名子程序，否则会在编译时报错。第二个技巧是通过 `Exporter` 模块导出 `enable`、`mount` 等关键字，使它们在 builder 代码块内可直接作为函数调用。最精妙的是第三个技巧：这些 DSL 关键字在 `builder` 块外其实是会报错的占位符，仅在 `builder` 运行时被临时替换为真正的实现逻辑，从而实现了上下文内的“魔力”。 文章通过具体的代码示例，将 Perl 语言特性与 DSL 设计模式巧妙结合的过程清晰地展现出来，对于想理解框架元编程技巧或 Perl 高级用法的开发者来说，是一次直观的代码剖析。
关于http代理
这篇技术文章聚焦于一个网络基础问题：当使用HTTP代理时，目标域名的DNS解析究竟发生在用户客户端，还是代理服务器上？作者从两种典型的代理工作模式展开分析，厘清了其中的关键差异。 第一种是直连模式，常用于HTTP请求，代理服务器直接接收客户端发送的完整URL并转发，因此域名解析由代理服务器完成。第二种是CONNECT隧道模式，主要用于HTTPS，客户端先与代理建立TCP通道，随后在通道内进行TLS握手，此时代理服务器同样负责解析目标域名。 为了验证这一点，作者进一步使用Golang编写了测试代码，并设置环境变量来配置代理。测试结果表明，无论是HTTP还是HTTPS请求，Golang的标准库实现与curl的行为一致，域名解析都发生在代理服务器端。文章还揭示了一个有趣的实现细节：在Golang处理HTTPS请求时，代理的CONNECT握手与后续的数据传输是在不同的线程中完成的。 通过对比和代码验证，这篇文章清晰地解释了不同代理场景下的底层行为，对于理解代理工作机制、进行相关调试或开发都有直接的参考价值。
Java跨语言调用实现方案
这篇文章探讨了在大型分布式Java系统中，如何在不改变原有POJO发布方式的前提下，实现跨语言RPC调用。作者指出，随着业务扩展，上层可能采用PHP、Ruby等技术，而底层服务又可能需要用C++、Python来追求更高性能，这就对现有的、基于Java的RPC框架（如Spring Remoting）提出了跨语言兼容的挑战。 文章首先梳理了业界三大主流方案：Google Protocol Buffers、Facebook Thrift 和 Apache Hadoop Avro。作者分析了各自的优劣：Protocol Buffers 的序列化格式高效但RPC能力弱，生成代码有侵入性；Thrift 提供了完整的服务栈和强大的接口支持，但与现有Java RPC体系不兼容；Avro 的动态类型机制灵活，但学习成本较高。 最终，作者提出了一种“扬长避短”的混合解决方案：核心采用Protocol Buffers的序列化格式和代码生成能力，服务接口定义借鉴Thrift的模式，并兼容现有的RPC传输层；同时，利用Avro的Schema机制来实现对原有POJO对象的无缝序列化与反序列化。这套方案旨在保留现有Java RPC架构的同时，优雅地打通多语言互操作。文章还留下了具体实现细节，为后续分享埋下了伏笔。
java中文乱码解决之道（六）—–javaWeb中的编码解码
这篇深入分析了Java Web开发中最令人头疼的中文乱码问题，尤其聚焦于服务器与客户端交互的编码/解码链条。作者从用户发起请求的四种方式（URL直接访问、链接、表单GET/POST）切入，详细拆解了浏览器在编码URL路径和查询字符串时的差异——例如IE与Chrome/Firefox在处理同一段中文时，一个采用GBK而其他采用UTF-8，揭示了乱码产生的首要根源。 文章的核心亮点在于源码级剖析。它追踪了Tomcat服务器接收请求后的解码流程，展示了`CoyoteAdapter`如何通过`connector.getURIEncoding()`获取`server.xml`中配置的编码集（如`UTF-8`）来解析URI，并默认使用`ISO-8859-1`处理未指定的字符。对于请求参数，则解析了`Request.parseParameters()`方法的调用时机与逻辑。这些底层实现解释了为何配置不当或浏览器行为不一致会导致乱码。 最终，文章将整个过程归纳为“页面编码->服务器解码->业务处理->编码响应->客户端解码”的闭环，并强调在服务器-客户端交互环节集中设置正确的编码是解决问题的关键。对于需要彻底理清Java Web中文乱码链条的开发者而言，这是一份从现象到原理的清晰指南。
java中文乱码解决之道（五）—–java是如何编码解码的
这篇文章深入到了Java虚拟机内部，剖析了字符编码解码的核心机制。作者从I/O操作和内存处理这两个乱码高发场景切入，详细拆解了Java如何处理字符与字节之间的转换。 文章指出了一个关键点：乱码的“元凶”往往是编解码使用的字符集不一致。例如，在按字节读取UTF-8编码的文件时，若未在构造String时明确指定编码，Java会使用平台默认的GBK去解码，结果自然就乱了。更巧妙的是，文章揭示了字符流（如InputStreamReader）本质上只是一个“桥梁”，其底层仍在进行字节读取，并依靠指定的字符集完成解码。 在内存操作部分，文章通过分析String.getBytes()与new String()的源码，展示了StringCoding.encode()和decode()方法的工作流程。特别指出了一个隐藏逻辑：如果没有指定编码，系统会先尝试平台默认编码，失败则回退到ISO-8859-1。理解这套内部流程，能帮你从根源上理解乱码问题。