不是学框架，是看穿它

不是学框架，是看穿它：20 年政务开发里长出来的一种认知

写给那个拿到新框架先翻源码再写代码的自己。

从一个习惯说起

我拿到一个新框架，第一件事不是看官方文档的 Quick Start，而是翻源码。

不是因为我热爱读源码。是因为我需要知道一件事：它到底在干什么。

Activiti 说自己是一个工作流引擎。但翻开源码，它的本质就是：解析一张 XML 图，把节点和连线变成内存里的 Java 对象，然后沿着对象引用往下走。所谓的"流程流转"，就是把当前节点的指针挪到下一个节点。

知道这件事之后，很多原本不可能的操作就变成可能了。

我不是在夸自己。这是一个花了 20 年才养成的习惯——不是能力，是习惯。下面我用自己干过的几件事，把这种认知拆开来讲。

一、看穿本质：框架在替你做什么

大部分人用框架的方式是：照着文档配置，跑通了就不管了。出了问题再去搜。

但如果你知道框架在替你做什么，出了问题你就不需要搜——你自己就能推出来。

例子：Activiti 的用户表为什么能换成视图

Activiti 有三张用户表：ACT_ID_USER、ACT_ID_GROUP、ACT_ID_MEMBERSHIP。官方文档教你往里插数据，或者实现 IdentityService 接口。

我翻了源码，发现 Activiti 查用户就是写标准 SQL：SELECT * FROM ACT_ID_USER WHERE ID_ = ?。没有特殊存储过程，没有二进制序列化，没有缓存穿透机制。就是一条 SQL。

既然是 SQL，表和视图有什么区别？对查询来说，没有区别。

于是我 drop 掉三张表，建了三个同名视图，直接映射到业务系统的用户表。零同步、零 Java 代码、零接口实现。

这个方案不是拍脑袋想出来的。是看穿了"Activiti 查用户就是一条 SQL"这个本质之后，自然推导出来的。

例子：事务管理的空壳化

Activiti 自己管数据库连接，MyBatis 也自己管连接。业务表和流程表不在同一个事务里，流程提交了但业务回滚了，数据就脏了。

官方方案是用 Spring 统一管理。但我的项目没有 Spring，是自研框架。

我翻了 Activiti 的源码，发现它的事务管理就是三个方法：commit()、rollback()、close()。于是我继承了JdbcTransaction，把这三个方法全部架空——commit 不提交，rollback 不回滚，close 不关闭。Activiti 以为自己管着事务，实际上连接和生命周期全在我的框架手里。

这不是 hack，是理解了事务的本质就是这三个操作之后，做出的最简方案。

二、找到缝隙：在别人的框架里找到自己的路

看穿本质之后，下一步是找到框架的边界在哪里——哪些是它必须控制的，哪些是它以为自己控制了但其实可以绕过的。

例子：任意流转

Activiti 原生只能按 BPMN 定义的路径走。但政务场景是科长要直接跳到处长、退回到科员、转办到其他科室。BPMN 画不出这种路径。

我啃了两个月源码。最后发现：流程图在运行时就是内存里的ActivityImpl对象，节点之间的连线就是对象之间的引用。所谓的"走下一条线"，就是把当前指针从 A 节点挪到 B 节点。

那我是不是可以直接改这个引用？试了一下，可以。改完跳转完成，再改回去。不影响流程定义，不影响其他实例。

核心方法turnTransition()，就是这么来的。

Activiti 控制的是流程定义的路径。但它管不了运行时内存里对象的引用。这个缝隙，就是突破口。

例子：分支条件自动注入

业务人员画流程图经常忘记给分支连线加条件。开发时才发现缺条件，回头改 BPMN 不现实。

但 BPMN 就是一个 XML 文件。XML 可以解析。解析之后，sequenceFlow节点就是一行一行可读的结构。

我的方案：流程部署之前，扫描所有sequenceFlow，找到同一个源节点有多条连线的情况，自动注入${nextid=="连线id"}条件。

业务人员只管画图，条件框架自动补。他们甚至不知道有条件表达式这个东西。

缝隙在于：Activiti 要求条件在部署时存在，但没说条件必须是人工写的。机器写的也行。

三、不碰源码，弯曲但不破坏

这两个原则是我给自己定的底线：

1. 不碰别人的源码——不改 Activiti 的 jar 包，不 fork 分支。升级的时候不会被自己的改动拖住。
2. 弯曲但不破坏——可以绕过框架的限制，但不能让框架崩溃。跳转完了要把连线改回去，空壳事务要保证连接生命周期正确。

这两个原则看起来矛盾——你要绕过框架，又不破坏它？

不矛盾。因为你看穿了框架在做什么，你就知道哪些地方能动、哪些不能动。

• ActivityImpl的连线引用能动，因为跳转完改回去，其他实例完全不受影响。
• JdbcTransaction的三个方法能动，因为真正的 commit/rollback 由上层统一管理器控制，连接不会被泄漏。
• 用户表能换成视图，因为 Activiti 只做 SELECT，不做 INSERT。

每一步都是在"知道框架到底在干什么"的前提下，在安全范围内找到最短路径。

四、这种认知从哪来

说了这么多，这种认知不是天生的，也不是看书看来的。是 20 年踩坑踩出来的。

几个关键经历：

VC + PB 时代：PowerBuilder 的 DataWindow 把数据库查询、展示、编辑、保存全做到一个控件里。我后来用 Java 写框架时，脑子里一直有这个模型——能不能把重复的事情做到一个地方？

自研框架 Browise：十几年的框架，从 XML 配置进化到注解驱动，从事务散落各处到统一管理。每一版改进都是因为碰到一个痛点，想清楚了本质，然后找到最简方案。

政务审批的特殊性：政务场景的需求永远比框架设计者想的多。科长要跳签、处长要退回、会签部门随时变、业务人员不会写条件表达式。这些需求逼着你不能只当框架的使用者，必须理解框架的内部结构。

这些经历教会我一件事：框架是人写的，人写的就有边界。边界不是墙，是缝隙。找到缝隙，你就有了自由度。

五、这不是技术能力，是一种思维习惯

很多人觉得能改 Activiti 源码、能绕过框架限制，是因为技术强。不是。

是因为我在面对任何一个新系统时，都会问自己三个问题：

1. 它在干什么？——不是它声称自己在干什么，是它实际上在干什么。
2. 它的边界在哪？——哪些是它必须控制的，哪些它以为控制了但其实没有。
3. 最短的路径是什么？——不是最优雅的，不是最规范的，是在安全范围内最快的。

这三个问题不需要技术天赋。需要的是不甘心只当使用者的心态——拿到一个工具，总想拆开看看里面是什么。

这种心态不是学来的。是被真实的业务需求逼出来的——当科长说"我要直接跳到处长"，你搜遍了官方文档发现做不到，你不拆源码还能怎么办？

写在最后

这篇文章不是教你绕过框架。是告诉你：你不需要被框架牵着走。

框架的设计者不可能预见你所有的需求。当需求超出了框架的能力，你有两条路：一是换框架，二是看穿框架找到缝隙。

第一条路成本高，而且下一个框架也会有边界。
第二条路需要认知，但认知是可以训练的——每次拿到新东西，别急着用，先想清楚它到底是什么。

政务信息系统 20 年，框架换了四五个，语言换了三四种。但每一种新东西到手，我的处理方式都一样：先看穿，再使用。

这不是能力问题，是习惯问题。而这个习惯，什么时候开始养都不晚。