架构

事务不归引擎管：ITransactionTemplate，聚合一致性的最后一块拼图前三篇都在引擎里面打转：状态机住进实体、一致性交给聚合、状态写入收进命令面。这一篇跨出引擎半步，处理两个世界交界处的问题——

用 AI 迁项目有多爽？我把 Webpack 迁 Vite 的全过程记下来了摘要：Vue 2 + Webpack 4 冷启动 40 秒，我花两天迁到 Vite。很多个坑，有一半是贴完整报错给 Cursor 才定位的。AI 好用，但它的方案不一定能直接上生产。

Codex 源码导读：第五部分——事件出口与多入口适配例如工具调用完成时，Core 同时做两件事：因此，界面看到的是事件通知；模型下一轮读取的是 SessionState.history。流式增量可以先到界面，完成项与工具结果再进入会话历史；两条路径不是固定先后。

初学AI的小高

LangGraph断点恢复与幂等执行实战一个 Agent 已经完成资料检索和报告生成，正准备写入数据库，服务却重启了。重新调用整个工作流，前面的模型费用要再付一次；直接从中间继续，又可能把同一份结果写入两次。

Codex 源码导读：第四部分——上下文压缩与继续执行工具执行会让会话历史不断变长。Codex 在模型请求前检查上下文容量；达到阈值时，先用一次压缩流程生成摘要，替换当前工作历史，再继续同一个 Turn。

Codex 源码导读：第十部分——Session、Thread 持久化与 Memory这部分只抓三条线：需要进入模型历史的用户输入、完整模型输出、工具调用和工具结果，会进入 Session 的记录入口。这里以 record_conversation_items 为例：先把 ResponseItem 封装成带元数据的 ResponseItemEnvelope，再更新内存历史、记录持久化项并发送原始响应项通知。文本增量等实时事件不必先进入这条记录链。

据说幸运很容易

TestNG 分组接入现有框架：实现、踩坑与解法在现有框架基础上，加上groups字段对case进行分组，例如分成smoke, regression……

WEB 项目如何禁用 F12 等功能一、前言作为Web项目开发的程序员，我们调试Web前端代码的时候离不开的就是浏览器的F12功能，他是开发者的利器，但是项目上线后，基于安全方面的考虑，往往很多平台会想办法禁用F12功能，哪怕不能绝对，也想提高别人研究的门槛。本文将通过几种能打开F12功能的方式，逐一讲解。

Codex 源码导读：第六部分——模型请求与流式网络层run_sampling_request 将这些内容交给 client_session.stream()：

Codex 源码导读：第三部分——沙箱真实执行这一篇回答：单元 7-11 讲完了「要不要问、问了谁、答了怎么翻译」；可是批准之后，那条 rm -rf 到底是怎么被「关进笼子」跑起来的？答案不是运行时拦截，而是启动前把 argv 换掉。

引擎里没有 setStatus：状态迁移收口，不用状态机框架上一篇评论区最常见的问题其实是个"的反面"：大家不是问"任务状态谁能改"，而是问——"你不用状态机框架，迁移规则写在哪？"

开放接口限流从 20 改到 200 还是每分钟 20 次：拆完防重放+幂等+限流，我找到 5 个静默失效的坑上一篇拆 RedissonLockManager 时留了个尾巴：三参 tryLock(wait, lease, unit) 不启动 watchdog。这次把上层真正调用它的开放网关链路扒了一遍——446 行的 forge-starter-openapi-security + 能力开放网关的九步编排，坑比预想的多，而且这条链路是真实跑在生产上的，不是我读源码推演的。

据说幸运很容易

接口测试框架重构：YAML 用例驱动 + 分层设计将接口测试按职责拆分为数据、驱动、执行、断言、API 封装等独立板块，让项目结构更清晰，每个文件只负责单一职责，避免逻辑杂糅。

聚合边界：为什么 ProcessTask 没有自己的 Repository上一篇（DDD 系列 ①）我用两笔账回答了"贫血和充血差在哪"。后台收到一个很合理的质疑，今天专门回答它：

一行 SET NX PX 的分布式锁，四个坑一个比一个贵这行命令，是很多人对"分布式锁"的全部理解：一条加锁、一条解锁，二十分钟写完，测试环境跑得欢。直到某天凌晨，对账报出同一笔订单被处理了两次。你翻代码：明明加锁了，SET NX PX，教科书写法。问题恰恰在这——这行命令是对的，但它的"对"只够你走到第一个坑。

99.9% 置信被拒收，76% 靠两个佐证进场99.9% 置信的判断被拒之门外，76% 的判断带着两个独立佐证进了场。决定一个判断能不能改权限状态的，不是分数的嗓门。

stateless 4/6 漏判，stateful 3/5 错杀：该信谁？一次 3/5 对 5/5 的输局，主角是我自己维护的项目。这场对照实验的第一幕它赢得干净：6/6 全对，对手 4/6。第二幕立刻被打回原形：3/5，对手 5/5。两幕各自的两条臂，吃的是同一份判断流，变的只有一件事——判断到达之后，系统拿它做什么。

同一个审批流引擎，我写了两次：一次 11226 行，一次 7036 行几年前，我给自己的快速开发框架写了一套内置工作流模块：流程定义、流程实例、任务、会签、退回，审批流该有的都有，用得也挺好。后来我把引擎从业务工程里抽出来，做成独立的 SDK，就是现在这个多语言工作流引擎 jeeflow。

这个DBA有点耶

数据库部署架构深潜：集中式、分布式、云原生的技术原理、演进逻辑与选型框架大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！中国信通院《2024数据库发展白皮书》显示，超过六成的政企用户在核心系统升级中，将“架构可演进性”列为关键选型维度。然而在实际技术选型中，集中式、分布式、云原生这三个概念经常被混用——很多团队以为自己在做分布式架构，实际上只是主从集群；而真正需要水平扩展的场景，又可能因为误判被局限在集中式方案中。

混合检索到底在混什么：为什么纯向量检索会认错人——Hybrid RAG 系列之一一句话价值：RAG 的检索不能只靠向量。向量能抓住「意思像不像」，却抓不住「词对不对」——专业术语、人名、订单号这类精确实体，纯语义检索会认错人。混合检索就是让「关键词检索」和「语义检索」互补，用两套索引各管一半，再融合成一份结果。这是检索从「能查到」到「查得准」的关键一步。