文章

通常在Spring Boot项目中，包结构如下： com.company.project entity mapper service controller 实践发现，随着项目越来越复杂，类越来越多，这种组织方式存在明显问题：同一个数据或业务相关的多个类分散在相隔甚远的不同包中，而编写、阅读代码却又是一起的，所以，在IDE中需要反复上下滚动，来找到需要的类，麻烦、效率低、不清晰。 在backend项目中，我们以数据或业务为中心组织包结构，包结构如下： com.company.project domain：领域包 entity/business：实体/业务包 data：数据包 mapper：Mapper包 service：服务包 controller：控制器包 scheduler：调度器包 领域包：表示一个业务领域，例如某个部门专门负责的业务。领域下可以再划分子领域。 实体/业务包：表示一个实体（例如项目、合同），或者一项专门的业务（例如对某数据的分析）。这是代码组织的基本粒度单位，包内的所有代码都是围绕某个实体/业务进行编写的，相关的服务、控制器等类全部集中在一起，方便编写和阅读。实体/业务包中提供数据结构（data包）和操作（service包），这是面向对象思想在包层次上的体现。 数据包：定义数据结构。之所以叫“数据包”而不是“实体包”，是因为数据不仅仅是实体类，还有枚举、表示某种共性的接口、常量等。 Mapper包：存放Mapper接口，实现数据库层面的操作。我们约定，凡是数据库层面的操作，只要能在Mapper接口中实现，就一定在Mapper接口中实现，因为这可以使Mapper层和服务层的职责更清晰，简化服务层。可以通过default方法、private方法、Mapper互相调用等手段来实现这一点。 服务包：存放服务类。服务层是实现业务逻辑的核心，是对外提供操作的核心，其他实体/业务只能通过服务层的方法来使用本实体/业务的操作。通过精心设计服务层方法的粒度，可以实现良好的代码复用。 控制器包：存放控制器类，对前端提供API。 调度器包：存放调度器类，实现定时任务。我们约定，定时任务必须通过调用控制器层来执行，而不能直接调用服务层，这是因为我们经常有手动触发定时任务的需求，手动触发会通过控制器层的API来执行，所以为了避免不一致，故做此约定。换句话说，调度器只是提供了一个定时触发的机制而已，无论是定时触发还是手动触发，执行都是从控制器层开始的。

我们之前有一个Java后端项目，但一直是野蛮生长的状态，简单粗暴地堆叠功能，没有经过良好的设计，没有制定统一的开发规范，每个人的代码都是不同的样子，每个人不会也不敢复用别人的代码，这些问题导致后续的开发、维护越来越艰难、低效。 我现在是公司内部信息化的技术负责人，从长远考虑，我认为有必要通过架构设计来解决这些问题，提升软件质量和团队效率。 经过分析评估，基本技术选型如下： 新起项目。 原因：仔细评估后发现，新的架构设计无法在老项目上实施，必然会遭遇无数兼容性问题，我们开发资源不够，不足以充分解决这些问题，那么必然会导致新旧代码都受影响。新起项目可以甩开历史包袱，旧代码按需逐步迁移即可。 单体项目。 原因：考虑现有的业务量、用户规模和开发资源，单体项目是足够的。微服务等分布式架构，目前不适合，强行上反而会使问题复杂化。 编程语言：Java 21。 原因：现有系统使用Java开发，现有人员擅长Java，因此语言选择Java。Java 21是当前最新LTS版本，有很多易用的新特性，值得拥抱新技术。 开发框架：Spring Boot 3，MyBatis。 原因：业界最常用，熟悉。选用框架的最新版本。 我将新项目的名称定为backend，意在作为以后的统一后端项目。 本项目将首要解决良好设计、开发规范、代码复用等过去的痼疾，提升软件的正确性、可维护性。配合团队管理（统一思想培训、代码评审等），本项目从诞生起就要严格控制代码的准入门槛，并以每一个实际需求为案例，不断迭代、优化架构设计。

公司网络结构调整，我们需要批量迁移OA系统的代码块中的JS文件地址。代码块在数据库中是以密文形式存储的，22年我们曾尝试过手动编辑和前端自动化脚本的办法，但总归是效率低下，治标不治本。现在我们有了逆向工程手段，可以从根本上解决问题。 分析OA系统的反编译代码，得知其使用的加解密库为org.bouncycastle:bcprov-jdk15on:1.52，所有类型的代码块（流程布局、建模布局、建模查询）的加解密过程完全相同。提取加解密过程，封装为工具类： package com.company.project.util; import org.bouncycastle.crypto.engines.AESFastEngine; import org.bouncycastle.crypto.modes.CBCBlockCipher; import org.bouncycastle.crypto.paddings.PaddedBufferedBlockCipher; import org.bouncycastle.crypto.params.KeyParameter; import org.bouncycastle.crypto.params.ParametersWithIV; import org.bouncycastle.util.encoders.Hex; /** 代码块工具类 */ public class CodeBlockUtils { private static final byte[] BYTES1 = "WEAVER E-DESIGN.".getBytes(); private static final byte[] BYTES2 = "weaver e-design.".getBytes(); /** * 将明文编码成密文 * @param source 明文 * @return 密文 */ public static String encode(String source) { try { if (source.isEmpty()) return ""; PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new AESFastEngine())); cipher.init(true, new ParametersWithIV(new KeyParameter(BYTES1), BYTES2)); byte[] outputBytes = new byte[cipher.getOutputSize(source.getBytes("GBK").length)]; int length1 = cipher.processBytes(source.getBytes("GBK"), 0, source.getBytes("GBK").length, outputBytes, 0); int length2 = cipher.doFinal(outputBytes, length1); byte[] resultBytes = new byte[length1 + length2]; System.arraycopy(outputBytes, 0, resultBytes, 0, resultBytes.length); return new String(Hex.encode(resultBytes)); } catch (Exception e) { throw new RuntimeException(e); } } /** * 将密文解码为明文 * @param encoded 密文 * @return 明文 */ public static String decode(String encoded) { try { if (encoded.isEmpty()) return ""; PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new AESFastEngine())); cipher.init(true, new ParametersWithIV(new KeyParameter(BYTES1), BYTES2)); byte[] sourceBytes = Hex.decode(encoded); cipher.init(false, new ParametersWithIV(new KeyParameter(BYTES1), BYTES2)); byte[] outputBytes = new byte[cipher.getOutputSize(sourceBytes.length)]; int length1 = cipher.processBytes(sourceBytes, 0, sourceBytes.length, outputBytes, 0); int length2 = cipher.doFinal(outputBytes, length1); byte[] resultBytes = new byte[length1 + length2]; System.arraycopy(outputBytes, 0, resultBytes, 0, resultBytes.length); return new String(resultBytes, "GBK"); } catch (Exception e) { throw new RuntimeException(e); } } } 使用OA系统中存储的所有代码块对工具类做全量测试，确认加解密结果一致。 那么，我们就可以在此基础上，进一步实现代码块内容的查找与批量替换。

实现本地运行 OA系统遵循Java EE的JAX-RS规范来实现Web API，我们当然也必须遵循之。 JAX-RS本身只是一种规范，运行它还需要实现了这种规范的框架（通常为Jersey），以及Web容器（Jersey在Web容器上注册Servlet来接收请求）。OA系统使用的JAX-RS框架是Jersey，使用的Web容器是Resin。 要在本地运行Web API，只需要让我们的框架在本地具备（<scope>provided</scope>）JAX-RS规范（javax.ws.rs:javax.ws.rs-api）和Jersey框架（com.sun.jersey:jersey-bundle），并运行在本地的Web容器（Tomcat）中即可。 为了让Jersey能扫描到我们的控制器类，需要在web.xml中（本地和线上）修改<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>的<param-value>值，将我们应用的包名附加到最后。 控制器类 JAX-RS使用@Path注解标记一个方法是一个资源（即一个API），使用@GET/@POST注解标记资源对应的HTTP方法，使用@QueryParam、@PathParam等注解获取请求中的参数，使用@Produces注解设置响应的内容类型（Content-Type）。@Path写在类上可表达公共路径前缀，@Produces写在类上可统一设置响应的内容类型。 可见，JAX-RS的基本使用跟Spring Boot的控制器是类似的，因此我们仍然称有@Path注解的类为控制器类，但它们的运行机制不太相同。在Spring Boot中，一个控制器类是一个Bean，全局只有一个实例。但在JAX-RS中，对于一个@Path类，每当一个HTTP请求映射到它时，它都会创建一个新的实例来执行。因此，我们的控制器类不能作为Bean管理。 为了简化控制器类的代码，我们编写所有控制器的抽象基类BaseController： // 所有API均返回JSON响应 @Produces(MediaType.APPLICATION_JSON) public abstract class BaseController { public BaseController() { // 注入依赖 IoCContainer.injectDependencies(this); } } 业务的控制器类继承自BaseController： public EntityController extends BaseController { @Resource private EntityService entityService; @GET @Path("/getEntity") public Entity get() { ... } } 自动数据库事务管理 我们希望执行一个API请求时，如果正常返回则自动提交数据库事务，如果发生异常则自动回滚数据库事务。 因为JAX-RS最终也是基于Servlet实现的，因此我们可以使用Servlet中的过滤器（Filter）机制，实现请求前、后的拦截，并在其中实现统一异常处理和自动数据库事务管理。 // 只拦截我们应用的API @WebFilter("/my/*") public class MyFilter implements Filter { @Override public void init(FilterConfig filterConfig) {} @Override public void destroy() {} @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { try { // 当前请求线程获取数据库连接 ConnectionHolder.getConnection(); // 对于HTTP响应，做统一异常处理 if (response instanceof HttpServletResponse) { HttpServletResponse httpResponse = (HttpServletResponse) response; // HTTP响应包装器，重写方法，避免响应在其他Servlet或Filter中被提交导致无法修改响应体内容 HttpServletResponseWrapper httpResponseWrapper = new HttpServletResponseWrapper(httpResponse) { @Override public void sendError(int sc, String msg) {} @Override public void sendError(int sc) {} @Override public void sendRedirect(String location) {} }; try { // 执行 chain.doFilter(request, httpResponseWrapper); // 执行成功，提交数据库事务 ConnectionHolder.commit(); } // 捕获任何抛出，进行统一异常处理 catch (Throwable e) { // 回滚数据库事务 ConnectionHolder.rollback(); // 响应结果map Map<String, String> resultMap = new LinkedHashMap<>(); resultMap.put("error", e.getClass().getSimpleName()); resultMap.put("message", e.getMessage()); // 写入HTTP响应 httpResponse.setStatus(500); httpResponse.setContentType(MediaType.APPLICATION_JSON); httpResponse.getWriter().write(JSONUtil.toJsonStr(resultMap)); } } // 对于非HTTP响应，不做处理 else { chain.doFilter(request, response); } } finally { // 当前请求线程关闭数据库连接 ConnectionHolder.closeConnection(); } } }

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按顺序绘制顶点，因此存在弧交叉、弧穿越顶点的问题，但总体上绘图结果还是很好的。