拆迁台账系统如何避免失控：建模与状态机设计

简介：这是一份关于征地拆迁与房屋安置管理系统的设计文档，面向政务信息化开发人员、项目经理及相关专业学生。文档从系统设计全过程切入，详细梳理了业务流程图，并重点分析了两类需求：功能性需求涵盖系统设置、征地拆迁、房屋安置、统计汇总、地理信息应用与移动办公应用六大模块，非功能性需求则关注可靠性、性能、安全性及可维护性；同时介绍了模块化、灵活性、可扩展性等设计原则，给出了基于J2EE的B/S/S总体架构、部署结构和技术路线。文档还专门讨论了移动办公与地理信息应用等扩展功能，体现了现代政务系统对空间数据和远程协作的支持。资源共一个docx文档，压缩包大小613KB，目录结构完整，章节按背景、系统目标、需求分析、总体设计展开，正文篇幅较为充实。当前已有153人学习，适合需要快速掌握系统设计文档写法，以及正在开展相关项目设计的人员参考。

1. 为什么说拆迁台账塞进 Excel 之后必然会失控

做城市更新或土地整理项目的同学应该都见过这个场面：街道办手里压着几箱子纸质协议，桌面上 Excel 开了十几个版本，同一个被征收人在不同表格里地址写法都不一样。征地拆迁与房屋安置管理系统的核心工作，不是把台账做成网页版 Excel，而是把入户调查、面积实测、评估公示、协议签约、审核签批、选房分房、补偿款发放整条业务链变成一条可追溯的数据流。

这套系统真正要解决三件事：数据口径统一（一本产权证只对应一份台账）、流程状态可控（没审核不能发款，没腾房不能选房）、资金与房源防重（一套房不能被两个人选走）。对后端开发来说，页面和 CRUD 都不难，真正的难点是业务状态机的边界划分和并发控制。下面按我熟悉的 Java + Vue3 前后端分离思路讲，MySQL 8 做业务存储，这套设计思路换到其他技术栈同样成立。

2. 台账数据建模：被征收人、房屋与协议的表结构怎么立住

征地拆迁与房屋安置管理系统里最容易返工的就是表结构。业务方一开始说"就是个花名册"，等做到签约环节又提出"每户要挂多个附件、每笔补偿款要单独走审批"，如果表没提前拆开，改动成本会成倍上涨。我的习惯是先认业务对象，再动手建表。

2.1 四个核心业务对象和它们的关系

这套系统的骨架是四个域：项目域、被征收人（房屋台账）域、补偿协议域、安置房源域。资金发放记录和档案附件属于辅助域，挂在被征收人台账下面，不单独作为表设计的起点。

有两处容易被忽略。第一，一本产权证可能对应多个被征收人，比如夫妻共有，台账表必须设计"主被征收人 + 家庭成员子表"，否则后面领款签字时缺少签字人，家庭成员提出异议也没有落脚点。第二，一个被征收人在一个项目下只能有一条台账主记录，但他的房屋如果住宅和商铺混搭，可以签多份补偿协议。所以业务关系的准确表述是：项目下台账唯一，台账下协议可多。

2.2 用一张被征收房屋台账表说明关键字段

下面这张表是整套系统的基础之一，建表语句把关键字段和约束都写出来了：

CREATE TABLE expropriation_household ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, project_id BIGINT UNSIGNED NOT NULL COMMENT '所属征迁项目ID', owner_name VARCHAR(64) NOT NULL COMMENT '被征收人姓名', owner_id_card CHAR(18) NOT NULL COMMENT '被征收人身份证号', property_cert_no VARCHAR(64) DEFAULT '' COMMENT '产权证号', cert_area DECIMAL(10,2) NOT NULL COMMENT '证载建筑面积，单位平米', survey_area DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '实测建筑面积', house_usage TINYINT NOT NULL COMMENT '用途：1住宅 2商业 3办公 4其他', structure_type TINYINT NOT NULL COMMENT '结构：1框架 2混合 3砖木 4简易', district_code VARCHAR(32) NOT NULL COMMENT '片区编号，关联数据字典', record_status TINYINT NOT NULL DEFAULT 0 COMMENT '0登记 1冻结 2待签 3已签 4腾房 5完结 6注销', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_project_household (project_id, property_cert_no), KEY idx_owner_id_card (owner_id_card), KEY idx_status (record_status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='被征收房屋台账表';

这段 DDL 里最值钱的是uk_project_household联合唯一约束：在同一个项目下，一本产权证只能出现一次，从数据层杜绝了重复签约和重复补偿。征迁业务里"人盯人"复查环节很多，但数据库约束比人可靠。另一个关键是owner_id_card必须留明文，后续签约金额计算、家庭成员关联都要靠它做连接键，一开始脱敏后面就做不了精确匹配。身份证号的脱敏展示放在查询层处理，存储层保持完整。

cert_area和survey_area分开存的原因也很直接：补偿通常按实测面积算，但证载面积是行政复议和审计时的重要依据。只存一个字段，后面做面积差异分析时没有数据支撑。house_usage直接决定补偿单价，必须做成字典表而不是代码枚举，政策调整时数据库改一行，不用发版。

2.3 状态字段和数据字典拆开存

record_status这类字段，我一般不在 Java 枚举里写死，而是建一张sys_dict_item字典表，核心字段只有五个：dict_type、item_value、item_label、sort_no、enabled。前端下拉框、后端校验、导出 Excel 的列头全从这张表查。原因很现实：征迁政策按年度调整，状态名和字典名会变，每次改文案都重新部署既慢又不安全。

台账表立住之后，这只是第一块地基。签约审核环节多人并发操作时状态字段会乱，所以第二步要把流程状态机设计好。

3. 签约审核流程的状态机：九个环节怎么流转不失控

3.1 从入户调查到档案归档的完整业务链路

征地拆迁的审批流转和普通 OA 不同，它的状态是单向主导、局部允许回退。完整链路常见做法是九个环节：入户调查 → 面积实测 → 评估公示 → 补偿方案确认 → 协议签订 → 街道初审 → 区级复审 → 腾空交房 → 资金发放或选房 → 档案归档。

这里"资金发放"和"选房"是二选一分支：货币补偿走发放补偿款，产权调换走选房，但不管哪条路，前面都必须经过区级复审通过。这就在状态机里划出一条硬边界：没有复审通过的单子，财务系统不能查到收款人信息。这个边界要做在权限模型上，而不是靠前端按钮——财务角色连"查看协议"的接口都调不到被征收人列表，才算真正控制住。

状态机设计最常见的失误，是把"当前状态"和"操作动作"混在一起存。比如有人把"待街道初审"和"街道初审退回"都当成状态存，结果列表筛选时同一单子的数据散在多行里。正确做法是状态只保存节点，操作结果（同意、退回、补充材料）记录在操作流水表里。

3.2 用状态机约束每一条流转路径

状态机的实现我一般用"静态配置 + 代码校验"的方式。下面是简化后的 Java 代码，核心是"当前状态、目标状态、操作角色"三元组放行：

private static final Map<Integer, Map<Integer, Set<Integer>>> STATE_MACHINE = Map.of( // 当前待签(3)：可以由调查员(2)提交到街道初审(4)，或退回登记(0) 3, Map.of(4, Set.of(2), 0, Set.of(2)), // 当前街道初审(4)：审查员(3)通过后到区级复审(5)，退回则回到待签(3) 4, Map.of(5, Set.of(3), 3, Set.of(2)), // 当前区级复审(5)：审批人(4)通过后发腾房(6)或直接走货币发放(7) 5, Map.of(6, Set.of(4), 7, Set.of(4), 4, Set.of(3)) ); public void transit(Protocol protocol, int targetStatus, int operatorRole) { Map<Integer, Set<Integer>> allowed = STATE_MACHINE.get(protocol.getStatus()); if (allowed == null || !allowed.containsKey(targetStatus) || !allowed.get(targetStatus).contains(operatorRole)) { throw new IllegalStateException("非法状态流转: " + protocol.getStatus() + " -> " + targetStatus + ", 角色: " + operatorRole); } protocol.setStatus(targetStatus); protocol.setVersion(protocol.getVersion() + 1); }

STATE_MACHINE的 key 是当前状态值，内层 key 是目标状态值，内层 value 是可执行这次流转的角色集合。比如"区级复审(5)通过后到腾房(6)"只允许审批人角色(4)操作，街道审查员不能越权。执行流转时还要配合台账表的version字段走乐观锁，UPDATE ... SET status = ? WHERE id = ? AND version = ?，防止两个审核员同时把同一条协议改成不同状态。这种事故在政务系统里出现一次就够写检查了。

状态机的价值在于把"可能的错"挡在前面。实际业务里会有"超期未处理"的场景，我一般不做自动流转，而是加一张flow_deadline表设置每环节 SLA，超时给经办人和分管领导发提醒。征迁涉及重大利益，自动跳转容易担责任，提醒让责任人自己决定就够了。

3.3 流程留痕表和角色操作权限

每次流转操作都要写一条流水，表结构如下：

CREATE TABLE flow_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, business_id BIGINT UNSIGNED NOT NULL COMMENT '业务主键ID', business_type VARCHAR(32) NOT NULL COMMENT '业务表名：agreement/household等', from_status TINYINT NOT NULL COMMENT '流转前状态', to_status TINYINT NOT NULL COMMENT '流转后状态', action VARCHAR(32) NOT NULL COMMENT 'submit/approve/reject/rollback', operator_id BIGINT UNSIGNED NOT NULL COMMENT '操作人ID', operator_name VARCHAR(64) NOT NULL COMMENT '操作人姓名', remark VARCHAR(500) DEFAULT '' COMMENT '补充说明', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_business (business_type, business_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='业务流转日志表';

日志表最大的用途是复现"用户说数据不对"的问题。比如有人说补偿金额算错了，查 flow_log 发现协议被改过；有人说选房总选不上，查 flow_log 发现房源被另一条业务提前锁了。idx_business联合索引一定要加，否则这个表过百万行之后查询会非常吃力。

权限矩阵建议做成角色-数据范围表，下面是这套系统里最基础的划分：

数据范围的过滤要在 SQL 层通过project_id和district_code做，Vue3 后台管理系统的前端隐藏菜单只是体验优化，不是权限边界。

4. 安置房选房与补偿资金计算：两处最容易出事故的规则实现

4.1 选房防重：数据库条件更新与乐观锁的取舍

安置房分配是这套系统并发压力最大的场景。政策通常是"按签约顺序选房"，签约完成得越早优先级越高。但签约是异步发生的，两个被征收人可能同时看中同一套房，前端按钮禁用拦不住，必须在数据库层挡住。

简单可靠的方案是条件更新搭配行级锁，一次 SQL 完成"判断可选 + 修改状态"：

UPDATE resettlement_house SET status = 'LOCKED', locked_by = #{operatorId}, locked_at = NOW(), version = version + 1 WHERE id = #{houseId} AND status = 'AVAILABLE' AND project_id = #{projectId};

这条 UPDATE 返回的影响行数就是判定依据：1 表示锁定成功，0 表示房源已被别人占用。锁定状态要有超时机制，比如 10 分钟内未确认就由定时任务回滚为 AVAILABLE，避免用户占着房源不选房、其他人干等。这里不推荐SELECT ... FOR UPDATE悲观锁，选房页面用户停留时间长，锁会一直占用数据库连接，高峰期容易把连接池打满。

房源表字段上有一个细节：楼栋和房间号必须拆成building_id、unit_no、room_no三个字段。政策里经常有"一定楼层以上另算差价"的分层定价，楼层要能单独参与计算，存成一个"房号"字符串后续只能靠正则拆，迟早要返工。

4.2 补偿金额计算：把标准和规则配置化

补偿计算是系统的另一条生命线。公式本身不复杂：住宅补偿 = 实测面积 × 片区评估单价 × 成新率系数 + 装修及附属物补偿 + 搬家费 + 过渡费。复杂的是政策会变，而且不同片区、不同房屋用途、不同建筑结构，套用的参数完全不同。

我的习惯是把每项标准做成参数表，而不是在 Service 里写死：

参数表至少要有effective_date、expire_date两个时间字段，业务计算时用协议签约日期去匹配生效区间。这里有个实际经验：政策常有追溯调整，今年签的协议可能去年就启动调查了，如果直接用"当前日期"查单价，补差价时结果会错。预计算逻辑代码：

SELECT param_value FROM compensation_rule WHERE param_code = #{ruleCode} AND effective_date <= #{signDate} AND expire_date >= #{signDate} AND enabled = 1

4.3 金额存储与前端展示的单位统一

金额处理上我强烈建议全系统以"分"为单位存整数。数据库 DECIMAL 本身精度没问题，但 Java 端只要有人把字段定义成 double 做中间计算，累计和明细就对不上账。用整数分后，入参时统一做一次"元转分"（BigDecimal 乘 100 取整），出参时在展示层除以 100，对账和打印都不会有误差。

补偿金额的字段还要保留一个"元"的展示位，只在协议 PDF 打印时使用，这是审计要求。数据表里存分，PDF 模板里用BigDecimal做格式化输出。这个约定要在团队文档里写清楚，否则 Vue 前端一不小心就把分当元传给后端了。

5. 上线前最该做的三个数据校验与排错手段

5.1 身份证号与面积差异的入库前拦截

身份证校验只做长度 18 位存活不了，看一个真实场景：系统录入"张三"的身份证11010119900307731X，长度对但校验位是错的，这类脏数据一旦进入台账，后续家庭成员关联、银行打款全部出问题。按 GB 11643 校验位算法写一个工具函数，入库前拦截：

def validate_id_card(id_no: str) -> bool: if len(id_no) != 18: return False weights = [7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2] check_chars = '10X98765432' try: total = sum(int(id_no[i]) * weights[i] for i in range(17)) return check_chars[total % 11] == id_no[17].upper() except ValueError: return False

这个函数的关键在第 17 位校验码计算，最后一位是数字或大写 X，必须统一转大写再比较。另外实测面积和证载面积差超过 15% 时，台账状态强制进入"复核中"，避免把测量误差直接带进补偿计算。这两个校验都不复杂，但能挡掉后续大半的"数据对不上"问题。

5.2 定时回滚任务要可手动暂停

选房锁定回滚的定时任务必须有手动开关。上线初期业务流程还没跑顺，经常出现"用户以为选了但实际没锁定"或者反过来，一键暂停回滚任务比改代码重启快得多。这个开关可以放在后台管理系统的参数配置页，而不是写死在配置文件里。

5.3 流程卡住时先看 flow_log 再看附件

当用户反馈"协议一直停在待签"，不要先翻业务表，先查 flow_log 里这条 business_id 的最后一条日志。如果流转时间正常而前台没显示，大概率是前端状态缓存问题；如果连日志都没有，那就是提交接口压根没调用成功。实际项目里状态卡在"待签"最常见的原因，是前端漏传了身份证附件，协议提交接口抛校验异常，页面却没给用户提示。

最后补一个运维细节：flow_log 表按created_at做分区或归档，这套系统跑几年后日志量会非常大，但不建议为了省事直接清表——审计随时会来调三年前的记录。分区键选created_at，按月分区，旧数据自动进冷分区，查询直接走分区裁剪，比加索引更稳。

本文还有配套的精品资源，点击获取