企业官网建设流程全解析

我们团队前段时间接了一个新农村信息平台的建设项目，我负责其中的土地资源管理子系统。老实说，接到需求的时候我以为就是个标准的业务CRUD，等真正下到乡镇调研了一圈才发现，这个“看起来不起眼”的系统，恰恰是整个平台里业务最复杂、数据最敏感、坑最多的一块。

这篇文章我会把完整的建设过程、技术选型逻辑、数据模型设计思路、核心功能落地细节，以及那些只有到了现场才会踩到的坑，全部梳理出来。一次性把“为什么这样做”讲清楚，而不是只贴一堆代码。源码我已经整理好放到仓库里了，需要的朋友直接对照着本文看即可。

1. 土地资源管理难在哪：从一张Excel引发的连锁问题

先说结论：土地资源管理子系统的核心难点，从来不是“开发一个增删改查页面”，而是如何用代码还原现实中那套又乱又敏感、还带历史遗留问题的土地台账逻辑。

1.1 村头的纸质台账与Excel，比你想的更不靠谱

我跟着调研小组去某乡镇了解情况时，发现村里还在用一本厚厚的纸质台账记录承包地信息。几百户人家、上千块地块，地块编号、面积、四至边界、承包人名字，全部手写登记。村干部为了应付检查，又把关键数据重新敲进Excel里。结果就是两套数据经常对不上，你说哪套是真的？哪套都有问题。

这里面最让人头疼的是面积口径：有按二轮承包时的合同面积算的，有按后来实测面积算的，还有按补贴面积算的。三种面积在同一块地上可能都不一样。所以系统里面积字段绝对不能只设计一个，至少得有三个维度的面积打底，否则后面做补贴核算、流转计价全部要翻车。

1.2 地块数据的三层关系：地、人、权

设计数据模型之前，我先画了一张关系脑图：地是物理存在的，人是活动主体，权是法律/行政上的归属。这三点在现实中经常互相纠缠，比如一块地可能同时有承包权、经营权、流转权，而这三类权利各自对应不同的人。

很多没接触过农村业务的开发者，上来就设计一张“土地表”，然后把承包人姓名、身份证号直接写进去。等到出现流转时，发现这块地已经被租给现代农业公司了，台账里却还是原承包户的信息，整个系统就废了。

所以我把数据模型拆成了三层：

• 地块基础信息（地块编码、面积、地类、坐标）
• 权属关系（承包关系、权属人、证件类型）
• 流转/业务记录（流转合同、审批记录、时间范围）

这样“人”和“地”的实际归属关系解耦，同一个物理地块可以随时间变化挂不同的业务记录，历史可追溯，业务也走得通。

1.3 子系统的定位：不是孤岛，而是承上启下的数据中台

这个土地资源管理子系统不是独立存在的，它是整个新农村信息平台的数据底座。村里的宅基地管理、农业补贴发放、土地流转合同备案，全部要挂在这套土地数据上。换句话说，土地数据错了，上面所有业务的数据都会跟着错。

因此在技术设计上，我给这个子系统预留了三类对外接口能力：

• 数据查询接口：供其他子系统读取地块、权属、流转信息
• 数据变更通知：土地数据变更时通过消息机制通知关联子系统（比如补贴系统需要重新核算面积）
• 审批回调接口：流转审批结束后，自动更新地块状态并记录操作日志

这样设计之后，土地子系统从“一个管理页面”变成了“一个数据枢纽”，在整体平台里的价值完全不同。

2. 技术选型：为什么是这个组合，而不是别家

这个项目最终确定的技术栈是：Spring Boot 2.7 + MyBatis Plus + MySQL 8.0 + Redis + Vue 3 + Element Plus。这套组合看起来非常“常见”，但每个选择背后都有具体的业务考量，不是随便拿来的。

2.1 单体应用优先，微服务先放一放

很多朋友一听说“平台”两个字就想上微服务，拆网关、拆注册中心、拆Nacos，最后维护成本比业务成本还高。这个项目真正的规模是：几十个乡镇，几千个村，用户量级撑死几万人，并发压力远没有想象中大。单体Spring Boot应用配合MySQL索引和Redis缓存，完全能扛住。

我采用的方法是模块化单体：按业务域分包（land、person、flow、file），边界清晰但部署还是一个包。这样既能保证开发效率，又保留未来拆分的可能性。说到底，微服务的核心收益是“独立扩展”和“故障隔离”，这个项目两者都不需要。

2.2 ORM选MyBatis Plus的原因：复杂查询与快速开发平衡

土地业务里有大量动态查询场景：按乡镇、按村、按地块编号、按面积范围、按权属人姓名，各种条件任意组合。要是用JPA那种强类型封装，写动态条件反而别扭。

MyBatis Plus提供了LambdaQueryWrapper，像这样：

LambdaQueryWrapper<LandParcel> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(query.getName()), LandParcel::getName, query.getName()) .eq(StringUtils.isNotBlank(query.getVillageCode()), LandParcel::getVillageCode, query.getVillageCode()) .between(query.getMinArea() != null && query.getMaxArea() != null, LandParcel::getContractArea, query.getMinArea(), query.getMaxArea()) .orderByDesc(LandParcel::getUpdateTime);

这类写法在业务系统里非常高效，既避免了手写大量XML，又保留了动态SQL的灵活性。不过分页我建议直接用MyBatis Plus的分页插件，它会自动拦截并生成COUNT查询，比手写LIMIT再加一个Count查询省事得多。

2.3 审批流：自研状态机，不引入Flowable

土地流转需要走审批流程：村级申请、乡镇审核、公示确认，可能还有县级备案。一开始团队里有同事建议引入Flowable工作流引擎，我当场否了。

理由是项目里的审批逻辑相对固定，流程节点不超过五个，其实是一个典型的状态机。引入Flowable意味着要维护单独的流程定义文件，要把流程引擎和业务数据同步起来，复杂度翻倍。最后我自研了一个简单的状态机核心，用状态枚举加状态流转表搞定：

public enum FlowState { DRAFT, // 草稿 VILLAGE_REVIEW, // 村级审核 TOWN_REVIEW, // 乡镇审核 PUBLICITY, // 公示中 APPROVED, // 已通过 REJECTED; // 已驳回 }

核心逻辑就一个：定义合法的流转方向，非法状态跳转直接抛异常。业务状态和流程状态分开存，流程状态自己走自己的状态机，业务数据保持稳定。这个设计后来证明足够可靠，维护成本也很低。

2.4 文件存储：本地目录+OSS备选方案

土地档案里面扫描件、权属证明照片、流转合同PDF是少不了的。我采用的方案是：开发环境直接存本地磁盘目录，生产环境切换到对象存储。Spring Boot的ResourceHandler可以很方便地映射本地目录为静态资源路径。

但在设计时要注意，文件路径不能直接存相对路径，而是存文件的业务关联ID + 文件类型，真正物理路径由服务端解析。比如附件表里存的是：

parcelId = "P202500001" fileType = "CERTIFICATE"

至于文件在哪个目录、叫什么文件名，全部由服务端从这个业务映射中计算出来。好处是以后迁移存储方案，业务表不需要动。如果直接把完整磁盘路径存进去，哪天换了服务器，所有路径全部失效。

3. 数据模型设计：地、人、权三层解耦的核心思路

这一部分我认为是整个子系统最关键的地方。很多项目做到一半推倒重来，基本都是因为表结构一开始就没设计好。

3.1 地块基础信息表：坐标系和面积口径必须死磕

我设计的核心地块表大概是这样的：

这里有个细节：面积字段必须用DECIMAL，不能用FLOAT或者DOUBLE。FLOAT存在精度丢失问题，在面积累加和补贴核算时会出大问题。土地面积动辄涉及补贴资金，差一分钱都要被追责。

坐标字段我直接用JSON类型存GeoJSON格式的边界坐标串。MySQL从5.7开始支持JSON类型，配合虚拟列和索引，在后面做空间查询时比较方便。虽然MySQL的GIS能力不如PostGIS，但处理乡镇级别的几千块地完全够用。

3.2 权属关系表：不覆盖历史，只新增记录

权属关系单独建一张表，而不是在地块表上直接写“当前承包人”。

public class OwnershipRight { private Long id; private String parcelId; private Long ownerId; private String ownerName; private String idCardHash; // 脱敏存储 private String relationType; // 承包权/经营权/他项权 private LocalDate effectiveDate; private LocalDate expireDate; private Integer currentFlag; // 是否为当前有效关系 }

这样设计的好处是，每次确权、变更、换证时，把旧记录标记为失效，新记录插入为当前有效记录。所有历史关系永久保留，随时可以查“这块地在2019年归谁”。以后遇到纠纷查证，系统能给出完整的链条，而不是只给一个最终结果。

3.3 流转登记表：每一条变更都要留痕

流转业务包括转出、转入、出租、入股等类型。我设计了流转登记表，结构中包含：

public class LandTransfer { private Long id; private String parcelId; private String transferType; // 转出/转入/出租/入股 private String fromParty; // 流出方 private String toParty; // 流入方 private BigDecimal transferArea; // 流转面积 private LocalDate startDate; private LocalDate endDate; private String contractNo; // 合同编号 private String flowState; // 审批状态 private String operatorId; // 操作人 }

这里要特别注意，流转面积不能直接从地块表引用总面积，必须单独存一个transferArea字段。因为很多土地流转不是整块地全流转，而是一块地拆开流转一部分，或者同一块地的不同区域做了不同的流转安排。

3.4 附件表设计：避免一张大字段表通吃一切

附件表我特意拆成了两张：一张存文件元数据，一张存业务关联关系。因为同一个附件可能被多个业务实体引用，比如一张地块照片既属于地块档案，也可能被流转合同引用。

最终的表结构是：

CREATE TABLE file_metadata ( file_id VARCHAR(32) PRIMARY KEY, file_name VARCHAR(200), file_type VARCHAR(50), file_size BIGINT, storage_path VARCHAR(255), uploaded_by VARCHAR(32), uploaded_at DATETIME );

然后用一张Map式的中间表管理业务关联：

CREATE TABLE biz_file_ref ( id BIGINT AUTO_INCREMENT PRIMARY KEY, biz_type VARCHAR(20), // LAND / TRANSFER / OWNERSHIP biz_id VARCHAR(32), file_id VARCHAR(32), created_at DATETIME );

这样不管以后哪个业务需要挂附件，都只需要往中间表插记录，不用动原来的表结构。

3.5 唯一索引与分布式ID的取舍

地块ID我一开始用了雪花算法生成的Long类型，后来项目里和村里的Excel台账对接时发现，人家根本不知道你的雪花ID是什么，他们只认自己的地块编号。所以最终落地时，地块表保留两个唯一键：内部ID（雪花）用于系统内关联，业务编号（代码如村编码+序号）用于对外对接。

而这个业务编号必须加唯一索引，否则批量导入Excel时一旦出现重复地块编号，数据库根本报不出错，只有业务上能感受到数据乱掉。

4. 核心功能实现：从地块建档到流转审批的全链路

这一节我把系统的核心功能拉通讲一遍，包括边界条件处理和细节设计。

4.1 地块档案管理：CRUD没你想的那么简单

地块档案的录入有两个入口：一是手工录入，二是Excel批量导入。手工录入走常规表单，批量导入是重点。

Excel导入我用的是EasyExcel，流程分四步：

1. 模板解析：读取Excel，按表头字段映射到对象
2. 前端校验：逐行检查必填字段、面积是否合法、编码是否重复
3. 导入预览：把校验结果返回给前端，显示成功和失败的行，用户确认后执行
4. 正式入库：再次校验后批量插入数据库

public ImportResult importLandExcel(MultipartFile file) { List<LandImportDTO> list = easyExcel.read(file.getInputStream()) .head(LandImportDTO.class) .sheet().doReadSync(); List<LandParcel> validList = list.stream() .filter(this::validate) .map(this::convertToEntity) .collect(Collectors.toList()); landParcelMapper.insertBatch(validList); return new ImportResult(validList.size(), list.size() - validList.size()); }

这里有个坑：一定不能直接入库后再扩展校验结果，否则极易造成Excel里三千行数据、插入了两千行，剩下的全是脏数据。导入预览功能看起来麻烦，但实际能保住数据质量，被领导表扬过很多次。

4.2 流转审批：状态机的边界保护

流转审批是典型的状态机场景。我在每个状态上都定义了“可以流转到哪些目标状态”，用一个Map存储：

private static final Map<FlowState, Set<FlowState>> TRANSITIONS = Map.of( FlowState.DRAFT, Set.of(FlowState.VILLAGE_REVIEW, FlowState.REJECTED), FlowState.VILLAGE_REVIEW, Set.of(FlowState.TOWN_REVIEW, FlowState.REJECTED), FlowState.TOWN_REVIEW, Set.of(FlowState.PUBLICITY, FlowState.REJECTED), FlowState.PUBLICITY, Set.of(FlowState.APPROVED, FlowState.REJECTED) );

审批操作执行时，先从Map里查当前状态能否到达目标状态，不行就直接抛出业务异常，说明“当前状态不允许执行此操作”。这套设计简单可靠，状态机一目了然。

特别注意：状态流转一定要配合操作日志。每次流转必须记录操作人、操作时间、操作前后状态、操作原因。这样后续审计才有数据支撑，出了纠纷能追溯。

4.3 地图展示与空间数据：地块边界不靠想象

系统里地块的坐标数据通过前端地图组件展示。我在后端提供了一个将全部地块封装成GeoJSON的接口：

@GetMapping("/land/geojson") public Result<GeoJsonObject> getLandGeoJson(String villageCode) { // 查询地块和边界坐标，组装成FeatureCollection返回 }

前端使用Leaflet加载GeoJSON图层。每个地块的坐标串在录入时可能来自GPS实测、也可能是从图纸上数字化出来的，精度差别很大，所以在界面上我对不同来源的坐标做了色区分，避免基层用户误解精确边界。

4.4 统计报表与补贴核算：一个接口解决多种口径

土地统计报表有：各村土地面积汇总、地类结构分布、流转面积统计、权属变更次数统计等。我直接用SQL的GROUP BY加条件统计，配合MyBatis自定义SQL，避免了在Java层做大量内存计算：

SELECT v.village_name, COUNT(DISTINCT l.parcel_id) AS parcel_count, SUM(l.contract_area) AS total_area FROM land_parcel l LEFT JOIN sys_village v ON l.village_code = v.village_code WHERE l.status = 1 GROUP BY l.village_code;

补贴核算的难点在于口径切换：按合同面积算还是按实测面积算，结果都可能不同。所以我在统计接口里加了一个areaType参数，由前端下拉决定，后端SQL根据参数动态选择SUM的字段。SQL拼起来会麻烦，但业务上很灵活。

4.5 文件上传与前端集成

文件上传我用Spring的MultipartFile接收，前端走Element Plus的Upload组件。上传过程中要拦截文件大小和类型，这里我直接在拦截器层面限定：

public boolean preHandle(...) { if (file.getSize() > 20 * 1024 * 1024) { // 抛异常 } String ext = StringUtils.getFilenameExtension(file.getOriginalFilename()); if (!allowedExts.contains(ext)) { // 抛异常 } }

绝对不能信前端传过来的文件名和后缀，要在后端重新判断扩展名。另外给文件改名时统一用UUID，避免中文文件名带来编码问题。

5. 并发与权限：在真实业务里必须处理的三个问题

这一部分经常被忽略，但恰恰是系统上线后被吐槽最多的地方。

5.1 同一块地被两个人同时改，怎么办

土地数据是共享数据，乡镇工作人员可能同时操作同一块地。如果不加保护，后提交的人会把先提交的人的数据覆盖掉。这里我用的是MyBatis Plus的@Version乐观锁，实体里加一个version字段，更新时自动带上条件：

@Version @TableField(fill = FieldFill.INSERT) private Integer version; // 调用更新时，MP自动拼上 WHERE version = ?

冲突发生时更新记录数为0，业务层检测到后提示“该数据已被其他人修改，请刷新后重试”。这套方案足够解决这类“低并发高冲突”的业务场景，比锁表简单太多。

5.2 数据权限隔离：村里人不能查全镇数据

系统用户包括县级管理员、乡镇干部、村级操作员。村级操作员只能看自己村的数据，乡镇干部能看全乡镇数据，县级管理员能看全部数据。

数据权限的落地方式，我在MyBatis Plus里写了一个自定义拦截器，拼上当前登录人在SQL层自动追加数据范围条件：

@TableField(fill = FieldFill.INSERT) private Integer version; // 思路：根据当前角色，自动追加 village_code 或 town_code 条件

具体逻辑是：在Mapper层之前，通过ThreadLocal拿到当前用户的数据权限范围，然后在SQL条件里附加限制。这比在后端手动判断每个接口要安全得多，防止通过拼接路径绕过单个接口的越权风险。

5.3 事务边界：不是所有操作都要一个事务

很多同学习惯在Service层统一加@Transactional，这样做一旦出现嵌套事务回滚，会引发非常难以排查的问题。我采用的原则是：

• 单个表更新快速完成，不需要事务
• 涉及多张表更新的操作（如流转审批、附件上传），必须加事务
• 批次导入虽然涉及大量数据，我特意分开事务，避免某条记录失败导致全部回滚

流转审批的事务核心代码：

@Transactional(rollbackFor = Exception.class) public void approveTransfer(Long transferId, String operatorId, String comment) { LandTransfer transfer = transferMapper.selectById(transferId); // 状态机校验 checkTransition(transfer.getFlowState(), FlowState.APPROVED); // 更新状态 transfer.setFlowState(FlowState.APPROVED); transferMapper.updateById(transfer); // 写操作日志 flowLogMapper.insert(FlowLog.create(transferId, operatorId, comment)); }

事务的粒度一定要按业务边界来划定，而不是图省事包一个巨大的方法。

6. 实测中的意外情况与排查链路：这些坑，你大概率也会踩

这是全项目最值得写的内容。下面挑四个最典型的坑，完整还原排查过程。

6.1 批量导入Excel时，地块编号重复竟然没报错

第一次导入测试数据时，Excel里有990行，其中有两行地块编号一样。程序没有报错，数据却插进去了两条同样编号的地块。直到做查询统计时才发现数据异常。

排查链路：

1. 查看数据库表结构，发现地块编号字段没加唯一索引
2. 查看导入代码，前端的校验确实做了查重，但查的是“已经导入过的编号”，同一个Excel内部的两条重复没有被处理
3. 修复方案：在导入解析阶段用Set做全量编号查重，同时在数据库加唯一索引兜底

这个案例的教训是：业务校验和数据库约束必须同时存在，不能只依赖其中一层。

6.2 坐标精度丢失：Double存储边界坐标被四舍五入

边界坐标初始用的Java的Double存储，一段时间后发现，图上展示的地块边界和GPS实测数据差了几十米。原因不是坐标系的问题，而是Double类型在存储大量小数位和做JSON转换时会丢精度。

排查链路：

1. 对比同一地块不同时间导出的GeoJSON数据，发现坐标小数位一直在变化
2. 查看实体类，发现坐标字段用的List<Double>
3. 检查数据库，JSON字段里存的是Double转换后的科学计数法字符串
4. 修复方案：坐标改存String类型，将经纬度小数位截断到6位，前端解析时再转为BigDecimal

土地坐标的精度要求很严格，经纬度的小数位至少要保留6位（对应约0.1米）。用String存储后，不会再出现浮点精度带来的偏差。

6.3 Excel导出大量数据直接OOM

一开始导出全乡镇的土地台账，数据量也就上万条，我以为没问题，结果第一次跑的时候JVM直接内存溢出。原因是查询时一次性把全量数据加载到内存，还通过EasyExcel的写Excel方式把所有对象都构建后写出。

排查链路：

1. 查看监控，发现堆内存持续走高，GC不能回收
2. 分析代码，发现一整条List全部在内存里
3. 修复方案：改用EasyExcel分批写出的方式，每查出一批（比如5000条）就写一批，配合后台异步生成文件下载

// 分批查询，配合 EasyExcel 流式写出 EasyExcel.write(outputStream, LandExportDTO.class) .inMemory(false) .sheet("土地台账") .doWrite(() -> { // 分页拉取数据并返回 return landMapper.selectPage(new Page<>(pageNum, 5000), wrapper).getRecords(); });

这样导出10万行数据也稳如泰山，内存占用始终保持在可接受范围内。

6.4 权限拦截器漏配了，一个普通村级操作员查到了全镇数据

这是权限模块唯一一次出生产问题。当时新加了一个统计导出接口，忘记在权限配置里加到受保护列表，导致已经登录的村级用户可以直接调用这个接口拿到全乡镇的数据。

排查链路：

1. 收到安全反馈后，第一时间检查新接口的注解配置
2. 发现配置列表里漏掉了该接口的白名单/黑名单设置
3. 修复方案：在拦截器里默认放行必须公开的接口，其余接口全部走鉴权，而不是配置“哪些需要鉴权”，改成“哪些不用鉴权”

这个设计思路很重要：默认拒绝、按需放行，比默认放行再一个个加校验要安全得多。

7. 经验总结与小技巧

做完这个系统，我最大的感受是：业务系统的复杂度往往不在代码本身，而在你怎么理解业务背后的数据结构和约束。土地资源管理听起来不复杂，真正落地时涉及面积口径、权属历史、状态流转、地图坐标、并发冲突、数据权限，每一个点都能让人防不胜防。

最后分享三个实操小技巧：

第一个，所有金额相关字段用DECIMAL存储，计算使用BigDecimal，避免Double精度坑。这在土地补贴、流转计价等场景里是红线。

第二个，日志一定要结构化。我采用的是JSON格式的日志输出，字段里包含操作人ID、业务ID、操作类型、耗时。排查问题时效率极高，不然出问题就要翻半天逻辑。

第三个，上线前用脏数据压一遍Excel导入功能，千万不要只用干干净净的测试数据跑一遍就验收。真实世界的Excel里什么烂数据都有，空白行、合并单元格、全角数字、科学计数法，不提前处理，上线第一天就会被投诉。

源码我已经整理好了，整个工程可以直接跑起来，语言级别用的Java 8，数据库脚本也一并附上。建议按照“先看表结构设计，再看状态机，最后看导入导出”的顺序去读，这样理解整个系统会比较快。如果调试过程中遇到问题，欢迎在评论区一起讨论。