企业官网建设流程全解析

1. 售后跟踪系统真正的难点不在"记录"，而在"状态流转"

很多人拿到"产品售后服务跟踪系统"这个题目，第一反应是做一个工单表：客户报修、填单、派单、修完关单，CRUD 走一遍就完事了。我一开始也这么想，后来发现真正把这类系统做废的，恰恰是把它当成了一个"表单收集器"。

售后业务的本质是一条有始有终、随时可能回退的状态链。一个报修单从"待受理"到"已受理"，到"已派工"，到"处理中"，到"待验收"，到"已完成"，中间还可能因为备件不到位挂起、因为客户改时间延期、因为处理失败退回重派。每一次状态变化都带着责任人、时间戳、操作原因和后续动作。系统如果只存了"当前状态"这个字段，那么过两个月客户打电话问"我那个单子到底卡在哪一步、谁在处理"，你和客服只能面面相觑。

所以我在设计这个系统的时候，把重心放在了状态机 + 流转日志 + 责任归属这三件事上，而不是把精力花在页面上堆功能。本文会围绕一个基于 Spring Boot 的售后跟踪系统，讲清楚领域模型怎么切、状态怎么设计、权限怎么落到数据行、超时怎么自动升级、统计怎么算才不糊弄人，最后再聊聊开发过程中我自己踩过的那些坑。适合正在做课程设计、毕业设计，或者要给中小型制造/零售企业搭一套轻量售后系统的朋友参考。

需要先说明一点：下面涉及的表结构、字段、接口设计，是基于这类业务常见做法给出的合理方案，不是照搬某个现成系统；具体字段命名你可以按自己团队的习惯调整，但设计思路和取舍理由建议保留，因为那些地方基本都对应着真实的业务痛点。

2. 先把领域模型切对：谁在报修、谁在修、修的是什么

2.1 四类核心实体和它们的关系

售后系统看着简单，实体一摊开其实不少。我最后收敛成四个核心实体，其余都是围绕它们的辅助表：

这里有个容易被忽略但非常关键的点：产品和客户不能简单绑死。现实中设备会转手、会调拨、会在不同门店之间流转，如果产品表里直接存一个customer_id，一旦设备归属变化，历史工单的客户信息就全乱了。我的做法是工单上同时冗余存一份customer_id和product_sn，产品表只维护"当前归属"，工单以创建时刻的快照为准。这叫快照优先于关联，在售后、订单、账单这类系统里几乎都是通用原则，值得记一下。

另一个细节是保修期判断绝对不能只靠产品表里的一个布尔字段。保修是算出来的：保修截止日 = 购买日期 + 保修时长，而保修时长又可能因为延保服务、不同部件不同政策而变化。所以我在产品表里存purchase_date、warranty_months、extended_warranty_end，工单创建时用一个服务类算出一个under_warranty快照值写进工单。为什么不实时算？因为保修政策会变，客户半年前报的单当时在保，半年后你改了口径，历史单据不能跟着变。凡是"会随时间或政策变动而改变结论"的字段，都应该在业务发生时快照落库，这个经验在计费、风控、合同类系统里同样适用。

2.2 工单号生成：别用自增主键当业务编号

工单号会印在纸质单上、发在短信里、被客户在电话里念出来。用数据库自增 ID 会有两个问题：一是暴露业务量（竞争对手下几单就能估算你的单量），二是分库分表后不唯一。我采用的是"日期 + 渠道码 + 序列"的组合，比如SO20240512A0007，其中A代表线上渠道，后面是当天该渠道的第 7 单。

生成逻辑用 Redis 的原子自增最省事：

public String generateOrderNo(String channel) { String day = LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE); String key = "seq:order:" + day + ":" + channel; Long seq = redisTemplate.opsForValue().increment(key); // 首次创建时设置过期，避免 key 无限堆积 if (seq != null && seq == 1L) { redisTemplate.expire(key, Duration.ofDays(2)); } return String.format("SO%s%s%04d", day, channel, seq); }

注意这个%04d：序列超过 9999 会自然变成 5 位，不要用截断，宁可位数不齐也不能重复。如果你不想引入 Redis，用数据库的SELECT ... FOR UPDATE配合一张序列表也能做，但并发高的时候会锁表，我实测过在每秒几十单的场景下数据库方案已经能感到排队，所以还是建议上 Redis。

2.3 故障分类要做成树，不要做成枚举

一开始我把故障类型写成枚举：硬件故障、软件故障、人为损坏。很快就发现不够用——客户说"屏幕不亮"，是硬件还是软件？派给谁修取决于这个判断。后来改成两级分类树，一级是"整机/部件/软件/外观/其他"，二级才是具体现象，并且每个二级分类上挂一个默认处理组。

这么改之后有两个好处：一是派单可以自动推荐处理组，二是统计的时候能按一级分类看趋势、按二级分类看具体问题集中在哪里。分类表结构就是经典的自关联：

CREATE TABLE fault_category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_id BIGINT DEFAULT 0, name VARCHAR(64) NOT NULL, default_group_id BIGINT COMMENT '默认处理组', sort_no INT DEFAULT 0, enabled TINYINT DEFAULT 1 );

提示：分类树一定要留enabled字段。业务调整时旧分类不能物理删除，否则历史工单的分类名就查不出来了。如果历史工单存的是分类 ID，那就更要用"禁用"代替"删除"，并在工单表里冗余存一份分类名称快照。

3. 状态机怎么设计，才不会被业务追着改代码

3.1 用枚举 + 迁移表约束流转，而不是散落各处的 if-else

这是整个系统里我最想强调的部分。如果你在 Service 层写if (order.getStatus() == 待受理) { ... } else if (...),那么三个月后这段代码会长成什么样，做过的人都懂。我的方案是把状态和允许的迁移抽出来：

public enum OrderStatus { PENDING(1, "待受理"), ACCEPTED(2, "已受理"), DISPATCHED(3, "已派工"), PROCESSING(4, "处理中"), SUSPENDED(5, "已挂起"), PENDING_CHECK(6, "待验收"), COMPLETED(7, "已完成"), CLOSED(8, "已关闭"); }

然后维护一张迁移规则表，或者在枚举里静态定义合法迁移集合：

private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = Map.of( PENDING, EnumSet.of(ACCEPTED, CLOSED), ACCEPTED, EnumSet.of(DISPATCHED, SUSPENDED, CLOSED), DISPATCHED, EnumSet.of(PROCESSING, ACCEPTED), PROCESSING, EnumSet.of(PENDING_CHECK, SUSPENDED, DISPATCHED), SUSPENDED, EnumSet.of(PROCESSING, CLOSED), PENDING_CHECK, EnumSet.of(COMPLETED, PROCESSING), COMPLETED, EnumSet.of(CLOSED), CLOSED, EnumSet.noneOf(OrderStatus.class) );

注意几个设计上的取舍：DISPATCHED可以退回ACCEPTED（派错人了）、PROCESSING可以退回DISPATCHED（换人）、PENDING_CHECK可以退回PROCESSING（客户验收不通过）。这些"回退边"恰恰是售后系统里最容易被漏掉的，而一旦漏了，上线第一天就会有人报"状态卡住了"。业务上真实存在的回退，一定要建模成合法的迁移边，而不是让管理员去数据库手动改状态——手动改一次，日志就断一次，后面所有统计都不可信。

3.2 每一次状态变化都必须落一条流转日志

工单主表只保留"当前状态"，历史全部进service_record。这张表是整个系统的价值核心，它同时承担了四个职能：操作留痕、责任追溯、时效统计、客户可见的进度展示。

CREATE TABLE service_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, from_status INT, to_status INT, action_type VARCHAR(32) NOT NULL COMMENT 'ACCEPT/DISPATCH/PROCESS/SUSPEND/FINISH/CLOSE', operator_id BIGINT NOT NULL, operator_name VARCHAR(64) NOT NULL COMMENT '冗余快照', remark VARCHAR(500), attachment_url VARCHAR(255), created_at DATETIME NOT NULL, INDEX idx_order (order_id), INDEX idx_created (created_at) );

operator_name冗余存一份，是因为员工可能离职、改名、调岗，而历史记录上必须显示"当时是谁处理的"。这是审计类数据的通用做法：外键保证当下的一致性，快照保证历史的可读性，两者不冲突，都要有。

写日志和改主表状态必须在同一个事务里。这里有个细节：状态迁移校验通过后，先写 record 再 update 主表，还是反过来？我建议先 update 主表并带上WHERE status = #{oldStatus}的乐观锁条件，影响行数为 0 就直接抛异常回滚。这样即使两个客服同时点"受理"，也只有一个能成功，另一个会收到"该工单已被他人处理，请刷新"的提示。这个并发细节在演示时不明显，但它是真实多人协作场景下的必需品。

3.3 挂起和关闭不是一回事，别合并

我见过不少系统把"挂起"和"关闭"混成一个状态，结果统计时分不清"正常完结"和"不了了之"。这两个在业务上差别巨大：挂起是暂时停摆、后续会恢复（等备件、等客户时间），关闭是终态、不再处理。挂起的工单要计入"在办"，关闭的工单要区分"完成关闭"和"取消关闭"。

所以我在记录表里用action_type区分FINISH（客户验收通过）和CLOSE（取消/作废），并在关闭时强制要求填写原因。强制填原因这件事，一开始团队有人抱怨麻烦，但正是这个字段让我们后来能分析出"30% 的取消是因为重复报修"，这个结论直接推动了去重校验功能的上线。凡是会丢失信息的操作，都值得加一道必填门槛。

4. 权限落到数据行：谁能看到哪些工单

4.1 角色只是第一层，数据范围才是真正的难点

售后系统里通常有几类角色：客服（受理、派单）、工程师（处理）、主管（查看全部、改派、审批）、客户（只看自己的单）。很多人做到"菜单权限"就停了，结果工程师能看到全公司的工单，客户能通过改 URL 里的 ID 看到别人的单——后者是安全事故级别的漏洞。

我的做法是每个查询都必须带数据范围条件，而且这个条件由框架统一注入，不靠开发人员自觉。实现上用 MyBatis 的拦截器比较自然，思路是：

1. 从当前登录上下文取出用户 ID、角色、所属组织；
2. 根据角色决定范围：客户 →customer_id = 自己；工程师 →assignee_id = 自己 OR group_id IN (自己的组)；主管 → 本组织全部；
3. 把范围条件拼到 SQL 的 WHERE 里。

关键点是第 3 步要拼到 SQL 层，而不是查出来再在内存里过滤。内存过滤有两个致命问题：分页数量不对（每页 10 条，过滤后可能只剩 3 条），以及一旦某个接口忘了过滤就泄露。SQL 层注入虽然实现复杂一点，但它是"默认安全"的。

4.2 客户侧的接口要单独设计，别复用后台接口

客户端的查询和后台的查询，字段需求和安全边界完全不同。后台要看到内部备注、责任工程师、成本；客户端只应看到进度、处理说明、预计完成时间。如果为了省事共用一个 VO，你迟早会在某个字段上出问题。

我采取的做法是分两套 Controller：/api/admin/orders和/api/portal/orders。客户侧接口在 Service 层强制附加customer_id条件，且这个条件不接受前端传参，只从 token 解析。这一点必须写进代码注释，因为后来接手的人很可能"顺手"加一个customerId请求参数，那就全线崩塌了。

注意：客户端接口返回的service_record也要过滤。内部备注（比如"该客户情绪激动，注意沟通"）绝不能出现在客户端可见的进度列表里。我的做法是记录表加一个visible_to_customer字段，写日志时显式指定，默认 false。默认不可见比默认可见安全得多。

4.3 改派和代操作要有独立权限

工程师之间互相帮忙处理是常态，但"谁能改派"必须收权限。我的规则是：工程师可以申请改派（产生一条待审批记录），主管可以直接改派。代操作（A 用 B 的账号处理）在系统里一律禁止，但提供了"协作人"字段，允许一个工单挂多个处理人，日志里记清楚是谁做的。这样既满足了协作需求，又保住了责任链条。

5. 超时、升级与提醒：让系统主动推着业务走

5.1 时效不是算出来的，是配出来的

售后系统的核心指标是响应时效和解决时效。这两个值不能写死，要按优先级、按客户等级、按故障分类分别配置。我建了一张 SLA 配置表：

工单创建时根据这三项匹配出一条 SLA，把response_deadline和resolve_deadline算好写进工单。又是快照——配置后续调整不影响已创建的工单，这个原则在本文里已经出现第三次了，因为它真的太重要。

时限计算还要考虑工作日历。直接加小时数会把周末和节假日算进去，导致周一早上系统里一片飘红。我建了一张work_calendar表存节假日和调休，计算时用循环跳过非工作日。这块逻辑不难但容易写错，建议单独抽一个DeadlineCalculator类，并配上单元测试覆盖"跨周末""跨长假""当天创建"这几个用例。

5.2 定时扫描 + 分级提醒，而不是只在页面上标红

页面上标红只有打开页面的人能看到，而真正需要被提醒的是"还没打开页面的人"。所以必须有一个定时任务主动推送。我用 Spring 的@Scheduled每 5 分钟跑一次扫描：

@Scheduled(cron = "0 */5 * * * ?") public void scanTimeout() { LocalDateTime now = LocalDateTime.now(); // 即将超时：剩余时间小于阈值的 20% List<ServiceOrder> warning = orderMapper.selectWarning(now, 0.2); warning.forEach(o -> notifyService.push(o, "即将超时")); // 已超时且未升级：按级别逐级通知 List<ServiceOrder> overdue = orderMapper.selectOverdue(now); overdue.forEach(o -> escalationService.escalate(o)); }

扫描的 SQL 要注意加索引，条件字段是status和resolve_deadline，建一个联合索引(status, resolve_deadline)很有必要。另外扫描要幂等：靠一张notify_log表记录"某工单某级别已通知过"，否则每 5 分钟给同一个人发一次消息，第二天就没人看你的通知了。

升级策略我设计成三级：超时 1 小时通知处理人，超时 4 小时通知其主管，超时 24 小时通知售后负责人并自动把优先级提到"紧急"。升级动作本身也要写进流转日志，这样复盘时能看清一个单子是怎么一步步烂掉的。

5.3 提醒渠道的选择与降级

站内消息是基础，但没人天天登录后台。短信和邮件要按重要性选择性使用——短信有成本，不能什么小事都发。我的策略是：即将超时发站内信，已超时发邮件，升级到第二级才发短信。同时所有通知走一个统一的NotifyService接口，渠道实现可替换，且发送失败要落库重试而不是吞掉异常。

public interface NotifyChannel { boolean supports(NotifyLevel level); void send(NotifyMessage msg); }

这样做的好处是后来接入企业微信/钉钉机器人时，只需要新增一个实现类，业务代码一行不改。通知这种外围能力，一定要抽象成接口，这是我在多个项目里反复验证过的低投入高回报设计。

6. 统计报表：别让口径问题毁掉整个模块

6.1 先定义清楚指标，再写 SQL

统计模块最容易出的问题不是技术，而是口径。比如"平均处理时长"，是从创建算到完成，还是从受理算到完成？含不含挂起时间？如果含，那一个等备件等了两周的单子会把平均值拉爆，管理层看到的数据就没法用。

我在系统里固化了三个口径，并在页面上明确标注：

• 响应时长= 首次受理时间 − 创建时间（衡量客服反应速度）
• 处理时长= 完成时间 − 首次受理时间 − 累计挂起时长（衡量工程师效率）
• 总时长= 关闭时间 − 创建时间（客户感知的端到端时间）

累计挂起时长需要在挂起/恢复时累加写入工单表的一个suspended_seconds字段，而不是查询时临时算。这是典型的用写入成本换查询成本的取舍，在报表频繁查询的场景下非常划算。

6.2 分档统计比平均值有用得多

平均值会被极端值带偏。一个月 100 单里有 2 单卡了一个月，平均值直接失真。所以我除了平均值，还提供分档分布：4 小时内完成、24 小时内、72 小时内、超 72 小时各占多少。这个分布图一出来，问题立刻就清楚了——如果 80% 的单子都在 4 小时内完成，但还有 5% 超过 72 小时，那说明流程整体是健康的，问题集中在少数疑难单上，该做的是给疑难单单独设通道，而不是全面加人。

SQL 上用CASE WHEN分桶即可：

SELECT SUM(CASE WHEN total_seconds <= 14400 THEN 1 ELSE 0 END) AS within_4h, SUM(CASE WHEN total_seconds > 14400 AND total_seconds <= 86400 THEN 1 ELSE 0 END) AS within_24h, SUM(CASE WHEN total_seconds > 86400 AND total_seconds <= 259200 THEN 1 ELSE 0 END) AS within_72h, SUM(CASE WHEN total_seconds > 259200 THEN 1 ELSE 0 END) AS over_72h FROM service_order WHERE created_at BETWEEN #{start} AND #{end} AND status IN (7, 8);

6.3 数据量大时的处理思路

工单表增长很快，一年几十万条很正常。报表直接查明细表，随着时间推移会越来越慢。我的做法是加一张按天汇总的统计表stat_daily，由定时任务在凌晨把前一天的数据聚合进去，报表优先查汇总表，需要下钻时再查明细。这个模式就是最朴素的预聚合，不需要上什么大数据组件，一张汇总表加一个定时任务，撑住中小企业的数据量完全够用。

另外，报表查询一定要限制时间范围，默认近 30 天，最长不超过一年。不限制范围的报表接口是定时炸弹，早晚会在某天早上把数据库拖垮。

7. 开发中真实踩过的几个坑

7.1 时间字段的类型选择

我一开始用LocalDateTime存所有时间，觉得比Date现代。上线后发现前后端时区对不上——服务器是 UTC，前端按本地时区展示，差 8 小时。后来统一规范：数据库存DATETIME且全部写本地时间，实体用LocalDateTime，序列化时统一配置时区，并且禁止在代码里出现new Date()与LocalDateTime.now()混用。这个规范写进了团队约定，比任何技术方案都管用。

7.2 附件上传的存储路径

工单附件（故障照片、维修单扫描件）直接存数据库会导致备份体积爆炸。改成存磁盘、数据库只存相对路径。但这里有个坑：如果多实例部署，本地磁盘就不通了。中小企业通常单机部署，本地磁盘可以接受，但一定要把存储根路径做成配置项，并且按年/月/工单号分目录，避免单目录文件过多导致文件系统变慢。将来要迁对象存储时，只需要替换一个StorageService实现。

7.3 状态字段的枚举值不要用中文

早期我图省事直接存"待受理"这样的中文字符串，后来要加多语言、要优化查询、要做前端映射，处处别扭。改成整型码 + 枚举类，展示层做映射，同时在字典表里维护一份码值说明，方便运营查看数据库时理解。数据库里存码，展示层存文案，这条原则几乎没有例外。

7.4 分页深翻页的性能问题

工单列表按时间倒序，翻到后面几万页时会明显变慢（LIMIT 100000, 20要扫描十万行）。优化方式是用游标分页：记住上一页最后一条的 ID 和时间，下一页查WHERE id < #{lastId} ORDER BY id DESC LIMIT 20。前端体验上也更自然——售后人员基本是"一直往下翻找最近的单"，而不是跳到第 5000 页。

7.5 别把导出功能做成同步的

导出 Excel 一开始是同步接口，数据量一大就超时。改成异步：提交导出任务 → 后台生成文件 → 站内信通知下载。任务表记录状态和文件地址，前端轮询或直接看消息中心。这个改造不难，但如果一开始不设计成异步，后面改动会牵连前端和接口协议。凡是可能超过 3 秒的操作，都按异步设计，这是我给自己定的线。

8. 一点个人体会

这个系统我在不同场景下改过两版，最大的感受是：售后跟踪系统的技术难度并不高，Spring Boot 加 MyBatis 加一个前端框架，几天就能搭出能跑的骨架。真正花时间的是那些"业务上确实会发生但文档里不会写"的细节——派错人要能退回、等备件要能挂起并扣除时长、员工离职后历史记录还要看得懂、客户不能看到内部备注、超时要有人被真的通知到。这些东西每一条都不复杂，但缺一条，系统就会在实际使用中被绕过，最后变成一堆没人维护的脏数据。

所以我给做这类系统的朋友一个建议：不要急着写页面，先拿一张纸把工单从生到死的所有路径画出来，包括所有回退和例外分支，然后逐个问自己"这一步谁来做、做不了怎么办、做错了怎么退"。这张纸画完，代码结构自然就出来了，而且能省掉后面大量的返工。至于技术选型，Spring Boot 生态足够成熟，把状态机、日志、权限范围、定时任务这四件事做扎实，这套系统就能真正用起来。