最新动态

IoC容器+依赖注入大大降低了对象间依赖管理的复杂性，给Java开发带来了极大的便利。我们的应用同样遵循这个设计思想。 考察OA系统中可能可用的IoC容器，发现都不适合我们： Spring IoC容器：Spring的版本为1.2.6，有IoC容器功能，但由于版本过早，不支持注解。 OA系统自己的IoC容器com.weaverboot.frame.ioc.container.WeaIocContainer：与OA系统各机制强相关，无法确定是否能保证我们应用的隔离性，有互相影响的风险。 其实我们需要的特性很简单： 只需要支持单例。 只需要按类型注入。 基于注解的Bean类扫描和依赖注入。 因此，我们自己实现IoC容器。 Component注解：具有此注解的具体类（非抽象类）将会作为Bean管理。 IoCContainer类： 使用Map<Class<?>, Object> beanMap保存每个类对应的Bean实例。 使用Hutool（在OA系统的三方库中）的ClassScanner扫描应用的包，对每个带有@Component注解的具体类，调用registerBean()注册Bean实例。 registerBean(Class<?> clazz)方法：先检查clazz在beanMap中是否存在，存在则不重复注册。不存在，则调用clazz的无参构造器创建Bean实例，并保存到beanMap中，然后调用injectDependencies()注入依赖。注意：这里要先保存到beanMap，再注入依赖，否则在循环依赖、自身依赖的场景下会无限递归。 injectDependencies(Object object)方法：遍历object所在类及所有祖先类的实例属性，如果属性有@Resource注解，且属性值为null，则按属性的类型获取Bean实例，并设置为属性值。如果该类型对应的Bean实例不存在，则先调用registerBean()注册之。 应用启动时，会调用IoCContainer扫描、注册Bean实例，并注入依赖，完成IoC容器的初始化。

OA系统使用weaver.conn.RecordSet类和weaver.conn.RecordSetTrans类来执行数据库操作，其中RecordSet不支持事务，RecordSetTrans支持事务。这两个类的代码量非常大，在没有文档和注释的情况下，仅通过逆向分析，我们根本无法保证能正确地使用其特性。因此，为了更加可控，我们自己实现数据库层。 数据源管理器 DataSourceManager类负责初始化数据源，并从数据源获取数据库连接。启动应用时，会调用DataSourceManager执行初始化。 初始化数据源：我们使用Druid（在OA系统的三方库中）作为数据库连接池。读取OA系统的数据源配置文件weaver.properties，用其中的配置创建DruidDataSource实例，并保存在DataSourceManager的静态属性中。 获取数据库连接：从DruidDataSource实例上获取数据库连接。 线程的数据库连接 ConnectionHolder类是一个ThreadLocal容器，用于保存当前线程的数据库连接，确保一条线程的所有操作都在同一个连接中，即在同一个事务中。 ConnectionHolder提供获取连接、关闭连接、提交事务、回滚事务这4个方法。 数据库服务 应用没有专门的DAO层框架，直接用JDBC模式操作数据库又很繁琐，因此，我们以服务的形式提供通用的数据库操作功能。 DatabaseService类是通用的数据库服务类，封装了通用的查库和写库操作的方法。此服务可以通过IoC容器注入到其他类中，应用中所有的数据库操作最终都是通过调用DatabaseService来完成。 DatabaseService使用Apache Commons DBUtils（在OA系统的三方库中）的QueryRunner来执行SQL。执行时，总是从ConnectionHolder获取数据库连接。 DatabaseService类提供以下查库方法： 方法 描述 查询结果为0行 查询结果为1行 查询结果为多行 queryRowOrNull 获取唯一行 返回null 返回唯一行 抛出异常 queryRow 获取唯一行 抛出异常 返回唯一行 抛出异常 queryFirstRowOrNull 获取第一行 返回null 返回第一行 抛出异常 queryFirstRow 获取第一行 抛出异常 返回第一行 抛出异常 queryRows 获取行列表 返回行列表（空） 返回行列表（1行） 返回行列表（多行） DatabaseService类提供以下写库方法： insert：插入 update：更新 delete：删除 所有查库和写库方法都支持参数String sql, Object... params，防止注入攻击。 通用的行数据结构 为了通用地表示DatabaseService查库方法查询到的任意结构的行数据，我们定义了Row类。 Row类是一个Map，类似于JavaScript的对象、Python的字典，可以表示任意的数据库行、实体、对象等数据结构。用Map表示对象，可以无需对属性做预定义，可以按需自由地增删属性，这带来了一些灵活性（例如：可以构造更新部分字段的更新数据对象，可以将一种对象修改为另一种对象，可以在字段增减时热更新程序），也降低了一些确定性（例如：IDE因为不知道有哪些属性而无法做代码提示和检查错误）。 Row类继承自LinkedHashMap<String, String>。考虑实际使用场景，我们对其做了一些约束。 键，即对象的属性名，是大小写无关的。通过重写Map的get()、put()等方法，统一将键转换为小写形式，来实现大小写无关性。 值，即对象的属性值，存储为字符串。通过重写Map的put()等方法，实现无论给的值是何种类型，都统一转换为字符串存储，其中null会存储为空字符串。通过增加getInt()、getBigDecimal()等方法，提供获取合适数据类型的功能。这种设计，屏蔽了数据类型的不确定性（例如：小数是Double还是BigDecimal），也使其不支持嵌套的对象。 对于Map具有的、但对对象来说意义不大的方法，如compute()，我们重写之并直接抛异常，以阻止其被使用。 应用中的各种业务数据类都继承自Row，或者直接使用Row。DatabaseService的查库方法支持泛型，可以返回指定的业务数据类（Row或Row的子类）。

OA系统的启动原理：OA系统在Web容器上注册了一个Servletweaver.general.InitServer。启动Web容器时，会执行InitServer的init()方法，OA系统就在该方法中启动，执行各种初始化操作。 同理，我们也可以在Web容器中注册一个ServletMyApplicationStartupServlet，实现启动： // 使用@WebServlet注解注册Servlet，可以免于修改web.xml。 // loadOnStartup：取最大整数，确保应用在OA系统启动之后才启动。 // urlPatterns：此Servlet不处理HTTP请求，但注解要求必填，所以这里给一个不会与OA系统冲突的路径即可。 @WebServlet(loadOnStartup = Integer.MAX_VALUE, urlPatterns = "/my") public class MyApplicationStartupServlet extends HttpServlet { @Override public void init() { // 启动应用程序，执行初始化 } } 应用启动时执行的初始化过程： 打印应用logo，类似于Spring Boot，这可以让我们在日志中更显著地看到应用启动。 初始化数据源。 初始化IoC容器。 对OA系统进行配置，例如动态注册免用户身份检查的API路径前缀（unchecksessionurl）。

总体思路上，我们要做一个相对独立的后端应用程序。 这个应用具有独立的分层设计，主要分层如下： 业务请求入口： 控制器层：接收来自Web API的业务请求。控制器类会注册到Web容器中。虽然API主要都写在我们的Spring Boot项目中，而不是写在这里（因为很麻烦），但仍然有部分涉及OA系统的API必须写在这里。 流程动作层：接收来自OA系统的执行流程动作的业务请求。流程动作类会注册到OA系统中。 服务层：实现业务服务，是业务逻辑的核心。 数据库层：实现对数据库的读写，支持事务管理。 应用与OA系统运行在同一个JVM中，可以在代码层面与OA系统进行交互。 应用将实现一个开发框架，这个开发框架将做到： 本地运行，方便调试：所有与OA系统非强相关的业务代码，都支持在本地运行，可以在Web容器上运行API，可以通过JUnit运行流程动作。本地运行时，可以方便地通过IDE断点做调试。 打包部署：整个项目可以打成一个jar包，然后整体上传、部署到OA系统中，方便更新和版本控制。 良好封装：框架对与OA系统的交互做良好封装，业务代码完全透明，或只需使用封装后的简单概念和接口，无需自己处理OA系统的复杂细节。 事务控制：一个业务请求（API或流程动作）的所有代码都运行在一个数据库事务中，支持自动提交和回滚。 开发规范：制定合理的开发规范，包括包结构、实体划分、服务粒度等，使业务代码更清晰有序、更可复用、更可维护。 由于本质上仍然是嵌入到OA系统中运行，应用面临如下限制： 部署后仍然要重启OA：必须重启JVM，才能使新代码生效。 三方库有限：应用只能使用OA系统自带的三方库，且必须同版本。为了避免影响OA系统，不允许向OA系统中加入其他三方库或已有三方库的其他版本。

我们的OA系统是泛微的Ecology 9。OA在走流程审批时，经常需要在到达或离开某个流程节点时，将流程中的数据保存到某个位置，或执行其他的业务操作。如果操作很复杂，就需要用代码来实现。OA提供了机制，让我们能写Java代码，部署到OA系统中，然后在流程的指定时机，调用我们的代码。 泛微给了我们这样一个开发框架：一个Java项目，依赖Maven库com.github.liuzhenghui:weaver-ecology-core:9.00.2102.17，这个库提供了Ecology 9的类结构，能编译，但不能本地运行。这个项目主要用来写流程动作和Web API。我们需要按规定在本地写好Java类，编译成class文件，上传到OA服务器中的指定目录，重启OA，然后执行它进行测试。如果要修改，则必须重复上述过程。 这个开发框架存在以下主要问题： 调试困难：不能本地运行，只能在服务器上运行，调试只能靠打印日志。 部署困难：只能逐个上传class文件，不能打包部署。多人、长期各自上传，使得class文件的版本难以控制。更新class文件后，要重启OA才能生效，重启时间很长。这种模式，使得我们不敢多写类，大量的代码挤在一个类中。 缺少封装：业务代码必须直面OA的底层机制，必须手动处理OA的元数据、权限等机制细节，缺少机制文档的情况下很容易出错。每个业务都要重复做这样的处理。 缺少事务控制：多个步骤中间出错时，会导致数据不一致。 缺少开发规范：只提供了与OA交互的基础机制，没有给出合理的程序结构，使得业务代码的组织相当混乱。 近期，我被调入公司新成立的信息部门，负责整个公司内部信息化的技术工作。同时，一个中等规模的独立业务系统需求被提到我们部门，与OA系统强相关。因此，我决定从这里入手，正式开始着手解决已经越来越明显的软件架构问题。 我将发起一个新的软件项目oa-backend-framework，从零开始对其进行架构设计，解决上述问题，积累架构经验，并用这个需求进行实战检验。 为什么不在上述开发框架上修改？已经尝试过了，但该框架与我的设计相差很大，修改势必带来很多冲突，导致两头都做不好。 OA系统本身就有成熟的架构和规范，为什么不遵循之？① 该架构是面向OA系统本身的问题域的，与我们的问题域并不相同；② 我们缺乏足够的文档信息和支持，对其架构和规范知之甚少；③ 基于已经了解到的信息，我们认为，即使遵循之，也无法完全解决上述问题，反而会带来新的麻烦。

项目表中存在如下3个字段： 项目编号：当前项目的编号。 前期项目编号：当前项目的所有前期项目的项目编号，包括前期的前期。 后期项目编号：当前项目的所有后期项目的项目编号，包括后期的后期。 数据示例：有A、B、C、D四个项目，关系如下图，存储结构如下表。 前期项目编号 项目编号 后期项目编号 - A B,C,D A B C,D A,B C - A,B D - 需要对系统中现存的项目前后期关系数据做校验、修正、简化、分析。 校验 校验前后期关系数据的完整性、一致性。 算法思想：如果A在B的前期中，则B一定在A的后期中。 # 获取项目列表 projects = ... # 映射表：项目编号 → 项目 map = {project["code"]: project for project in projects} for project in projects: code = project["code"] for previous_code in project["previous_codes"]: if previous_code not in map: print(f"{code} 的前期项目 {previous_code} 不存在") elif code not in map[previous_code]["next_codes"]: print(f"{code} 不在前期项目 {previous_code} 的后期项目中") for next_code in project["next_codes"]: if next_code not in map: print(f"{code} 的后期项目 {next_code} 不存在") elif code not in map[next_code]["previous_codes"]: print(f"{code} 不在后期项目 {next_code} 的前期项目中") 修正 针对校验出的问题，修正办法： 项目编号不存在：可能是项目编号改变了但未同步更新，修正项目编号，修正同步更新机制；如果真的不存在，则确认后删除。 B不在其前期A的后期中：在A的后期中补充B。 A不在其后期B的前期中：在B的前期中补充A。 多次运行校验，直到无错误。 简化 前期、后期字段这么设计，是为了做链接，方便从一个项目跳转到有前后期关系的任意项目，但这给我们分析前后期关系情况带来了麻烦。实际上，项目表中只需要存储项目编号+直接后期项目编号（不包括后期的后期）这两个字段即可，直接前期、所有前期、所有后期都可以通过这两个字段动态计算出来。因此，在校验并修正之后，我们对关系的存储结构做简化。 算法思想：首先确认不存在隔代后期关系，即在A→B→C的场景下，A→C一定是无效的。那么，对于任意一条弧A→B，如果存在顶点P，且同时存在P→A、P→B，则P→B一定是无效的。 # 遍历每一条弧 for project in projects: code = project["code"] for next_code in project["next_codes"]: # 找出同时满足p→code和p→next_code的顶点 for p in projects: if code in p["next_codes"] and next_code in p["next_codes"]: # 删除弧p→next_code p["next_codes"].remove(next_code) 分析 聚类 将有前后期关系的所有项目聚类在一起，构成一个个独立的项目群。 算法思想：求有向图的所有极大连通子图，用并查集实现。 # 项目编号的并查集，简单实现 # 初始每个项目编号是一个集合 disjoint_set = [{project["code"]} for project in projects] for project in projects: code = project["code"] for next_code in project["next_codes"]: # 找出code所在的集合set1 for set1 in disjoint_set: if code in set1: # 找出next_code所在的集合set2 for set2 in disjoint_set: if next_code in set2: # 如果set1不是set2，则合并为一个集合 if set1 is not set2: set1.update(set2) disjoint_set.remove(set2) 算法结束时，并查集中的每个集合就是一个项目群。 图形化 我们希望以图形的方式直观地看到每个项目群中各项目的前后期关系。 Python的networkx+matplotlib库可以实现图（graph）的绘制。绘制时，需要计算顶点的摆放层号，使得绘图结果清晰、美观。 算法思想：对图做拓扑排序，入度为0的顶点被取出的批次，就是顶点的层号。 # 映射表：项目编号 → 项目 project_map = {project["code"]: project for project in projects} # 项目群序号 order = 1 # 遍历项目群 for codes in disjoint_set: # codes表示顶点集合 # 只关注多顶点子图，不关注单顶点子图 if len(codes) > 1: # 弧集合 arcs = [ (code, next_code) for code in codes for next_code in project_map[code]["next_codes"] ] # 映射表：顶点 → 弧尾顶点集合 in_map = {code: set() for code in codes} for arc in arcs: in_map[arc[1]].add(arc[0]) # 映射表：顶点 → 绘图时的层号 layer_map = {} # 拓扑排序，入度为0的顶点被取出的批次，就是层号 layer = 0 while in_map: # 找出入度为0的顶点，得到层号 zero_degree_codes = [ code for code, values in in_map.items() if len(values) == 0 ] for code in zero_degree_codes: layer_map[code] = layer layer += 1 # 删除入度为0的节点 for code in zero_degree_codes: del in_map[code] for values in in_map.values(): values.discard(code) # 绘图 fig, ax = plt.subplots(figsize=(24, 13.5)) graph = nx.DiGraph() graph.add_nodes_from(codes) graph.add_edges_from(arcs) for code in codes: graph.nodes[code]["subset"] = layer_map[code] positions = nx.multipartite_layout(graph) nx.draw_networkx_nodes(graph, positions, ax=ax, node_size=10000) nx.draw_networkx_edges(graph, positions, ax=ax, arrowsize=20, min_target_margin=50) nx.draw_networkx_labels(graph, positions, ax=ax, font_color="white") ax.axis("off") plt.savefig(f"output/项目前后期关系图/{order}.png") plt.close(fig) order += 1 算法缺陷：由于networkx按顺序绘制顶点，因此存在弧交叉、弧穿越顶点的问题，但总体上绘图结果还是很好的。

公司的财务顾问使用Power Query技术制作了几个非常复杂的Excel文件，用于业务数据分析。业务人员知道如何使用这些Excel，可无法读懂其中的逻辑细节，出现问题时也无法解决。考虑到未来这些逻辑都需要我做到系统中，那么这些其实就是第一手的需求资料，于是我决定，主动帮助业务人员分析这些Excel的逻辑。 一、学习 首先了解并学习Power Query是什么，能做什么，有什么特性和限制，并做一些实验和demo来加深理解。 我理解到，Power Query其实是一种表处理语言，从一张表计算出另一张表。非技术人员通过Excel软件中的图形化界面来编排计算过程，但背后其实就是代码（M语言代码）。 二、提取元素和关系 将每个Excel中的主要元素逐个提取出来，包括： Excel文件（工作簿） 工作表（Sheet） 表格（命名单元格区域） 单元格区域（非命名单元格区域） 数据透视表 数据透视表的切片器 Power Query的查询 Power Pivot的数据模型 这些就是要分析的问题对象。我将它们用不同的图形表示出来，画在一张PPT上。 然后分析它们之间的关系，包括： 元素之间的包含关系，例如Excel文件与工作表、查询，工作表与表格、数据透视表。 Excel文件的输入关系，即Excel文件从哪个Excel文件取数。 查询的输入关系，即查询从哪些Excel文件、表格、其他查询取数。 查询的输出关系，即查询的结果被哪个查询取数，或输出到哪个表格，或输出到哪个数据模型。 数据模型的关系，例如数据模型从哪个查询取数、数据模型间的连接关系。 将这些关系用连线或箭头表示出来，同样画在PPT上。 整理PPT中的元素和关系，就得到了整体结构图。 三、理解查询代码 整体上的计算过程是： 输入：从表格或Excel文件读取数据。 计算：Power Query执行计算。 输出：将计算结果输出到表格。 那么接下来要重点分析各Power Query查询的计算过程。 首先将每个查询的代码都提取出来，逐个放到文本文件中。然后逐个阅读这些代码文件，尝试理解，并写注释。 这个过程的主要困难在于，代码是最末端、最具体的执行步骤。一个宏观上的意图，可能会表现为多条代码。限于表处理语言的机制（只能表算表），计算过程的表达形式跟我们常用的编程语言很不一样，很简单的一个操作，Power Query经常不得不写得很绕、很晦涩。此外，步骤都是图形化编排出来的，没有有意义的命名。所以，基本上跟读反编译代码差不多，主要靠推理和猜测。这里我采用自底向上的思路，先用自然语言描述出每一个步骤做了什么，再联系上下文猜测它的宏观意图是什么，最后跟业务人员同步信息确认理解是否正确。 我对每个查询都进行了仔细分析，阅读并注释了每一行代码，画出了数据流转关系图，写出了对宏观意图的理解，写出了对主要计算过程的理解，写出了对计算结果的描述（形式和内容）。 四、报告与讲解 我将分析出来的所有成果，写成了一个报告文档。文档先总述Power Query的基础知识、各个Excel文件之间的关系，然后逐个Excel详细描述分析成果，包括Excel文件内的各结构图、每个查询的分析、每个数据透视表的分析等。 我将报告文档提交给了领导和相关业务同事，然后在领导的要求下，给领导和同事现场清楚地讲解了整个逻辑。 五、价值 后来的事实证明，我的工作是非常有价值的。 我清楚地理解了这里面的每一个细节，成为了最了解这一块业务的人之一（甚至某些方面还要超过业务人员），能参与进跟财务顾问的讨论，能在后续上系统时帮助产品经理纠正理解上的不足和偏差，能在开发时有更高的效率。

做一个复杂的需求，要求对于同一份建模数据，不同的用户在新建、编辑、查看时使用不同的布局。实现时，先做一个完整的母版布局，然后复制出用户布局并修改。Ecology 9没有提供复制建模布局的功能，因此我们自己实现。 为了避免使OA系统出现未知的问题，我们限定，只允许在同一个模块内，复制一个已存在的布局到另一个已存在的布局。 从接口/formmode/exceldesign/excelLayoutSave.jsp?operation=saveExcel出发，逆向分析OA系统保存建模布局的机制，得出结论，只需复制以下表的数据即可实现复制建模布局： 表 数据内容 复制方式 modehtmllayout 布局自身的信息，例如布局设计、代码块等 update，注意保留布局名称 modeformfield 布局的字段信息，例如是否必填等 先delete再insert，注意复制到显示布局时字段全部变为只读 modefieldattr 布局的字段属性信息，例如计算日期差等 先delete再insert modeformgroup 布局的明细表信息，例如是否允许增行等 先delete再insert，注意复制到显示布局时关闭修改的相关配置 mode_layout_querysql 布局的明细表的固定查询条件 先delete再insert mode_layout_sortfield 布局的明细表的字段排序信息 先delete再insert

最近在开发一个非常复杂的需求，代码量巨大，为了清晰起见，必须拆分成多个JS文件，然后有序地组合起来。开发框架目前只支持将代码写在单个JS文件script.js中，因此需要修改。 考虑历史代码兼容性和开发周期，我决定采用一种简单的实现方案：文件包含。类似于C语言中的#include，我们在JS文件中做特殊标记，表明要将另一个JS文件的内容包含进来，然后在构建时用指定JS文件的内容替换这个特殊标记，这样就实现了分开编写、组合运行。 文件包含标记：在JS文件中用如下标记表明要包含哪个JS文件： //#include: A/B/C/xxx.js 解析文件包含： 迭代解析：A包含B，B包含C，通过迭代算法可以实现正确的链式包含。算法：循环检查A中是否还有包含标记，有则对第一个包含标记（B）执行替换，此时，如果替换的内容中带进来了新的包含标记（C），则会在下一次循环中被解析。 防止循环包含：迭代解析的过程中，要记住走过的文件有哪些，一旦发现要包含的文件之前已经走过，就说明出现了循环包含，报错。 动态监听：一个脚本文件现在可以拆分为多个文件，这多个文件又随时可能修改、增加、删除，则对于持续构建模式来说，要监听变化的文件范围是动态的。每次构建一个脚本文件时，都要重新计算并监听涉及的文件。 有了文件包含机制，我们就可以获得以下好处： 将单个复杂的任务分解为多个简单的任务，提高了清晰度、可维护性。 可以实现公共代码，免于复制粘贴，提高了代码复用度。 在OA系统的代码块机制中，多个<script src="...">之间的执行顺序是随机的，通过在同一个文件中控制文件包含的顺序，我们就可以严格控制多个脚本间的执行顺序。 文件包含机制也有其缺点： IDE不识别：标记是我们自己定的，IDE并不知道要包含哪个文件、文件间的顺序等信息，也就无法提供文件跳转、准确的代码提示等功能。 作用域不隔离：文件包含本质上是将代码拼在一起，是同一个作用域，并没有实现真正的JS模块化。编写代码时需要对这一点有清晰的认识，如果需要模块化，则必须自己用IIFE等手段实现。 不太容易理解：我开发的这个非常复杂的需求，其他同事在阅读代码时，不太容易跟踪和理解同一作用域、多层包含下的执行过程。 这些缺点，未来可以通过用Webpack实现真正的JS模块化来解决。

泛微OA系统Ecology 9的前端程序是经过编译、压缩后的JavaScript文件，为了深入研究其机制细节，我们对其做逆向工程，将压缩的JS代码还原为非压缩的JS代码，并对其进行分析、理解。 建立一个项目oa-frontend-reverse-engineering，将线上的JS文件下载下来，按相同的目录结构放在项目中。然后在本地用nginx做反向代理：如果一个JS文件在项目中，则取项目中的，否则取线上的。nginx配置如下： server { listen 80; listen [::]:80; server_name oa-frontend-reverse-engineering; root "<项目目录>"; location / { # 如果本地存在文件，则取本地文件 # 否则，通过反向代理，取OA系统上的文件 try_files $uri $uri/ @reverse_proxy; } location @reverse_proxy { proxy_pass http://<OA系统的IP地址>$request_uri; } } 浏览器通过http://oa-frontend-reverse-engineering/可以正常访问OA系统，其中部分JS文件取自本地，于是，我们不仅可以阅读代码，还可以通过实际执行、断点调试来深入理解细节。 注：后来Chrome系浏览器在DevTools的“源代码”功能中增加了“替换”功能，可以直接用本地JS文件替换指定的线上JS文件，这比做nginx反向代理更简便。以下是阅读、还原压缩的JavaScript代码的方法和经验： 第一步：用代码格式化工具（例如VSCode）将压缩的JS代码格式化为缩进良好的版本。 写注释。 利用编辑器、IDE的重构功能，将变量改为有意义的名字。 利用编辑器、IDE的代码跟踪功能，跳转到相关的上下文。但JS代码由于动态性高，通常难以跳转，转而利用搜索功能，用函数名、特殊字符串等关键信息查找上下文。 在分析过程中，熟悉!0、&&、||、模块化等常见的编译结果模式，理解JS语法原理，还原为对应的正常写法。 断点调试，跟踪执行。 临时改写代码，将某些对象、数据、函数暴露到window上，在控制台中查看、修改、执行之，这对状态存储数据尤其有用。 注意：还原出来的JS文件只允许用于分析，不允许替换线上的JS文件。