设计一个用于记录船代现场操作日志的系统，请说明其核心功能、数据结构（关键字段）和权限控制设计。
答案
1) 【一句话结论】设计一个基于状态机驱动的船代现场操作日志系统，通过状态机管理货物/船舶状态变更，结合消息队列保证日志实时性，并采用角色权限分级控制，确保操作可追溯、状态同步，数据完整。
2) 【原理/概念讲解】老师口吻解释：
核心功能分三块：
- 状态跟踪：用状态机表定义状态（如货物状态：待装、已装、待卸；船舶状态：靠泊中、离泊中），操作触发状态转换（如“装卸”操作使货物状态从“待装”变“已装”），操作日志记录状态变更。
- 操作记录：记录具体操作（如货物起吊、船舶靠泊），关键字段包括操作ID（UUID）、时间戳、操作人、操作内容、关联实体（船舶/货物ID）、当前状态。
- 审计追溯：支持按时间、船舶、操作人等维度查询，保留状态变更历史。
数据结构：
- 状态机表：存储状态定义与转换规则（如JSONB格式，定义“待装→已装”的触发条件为“装卸操作”）。
- 操作日志表：记录操作行为，包含状态变更字段（前状态、变更时间、触发操作ID），关联单证用JSONB存储。
权限控制：
- 角色表：管理员、操作员、审核员。
- 权限表：映射角色与操作（如操作员可提交日志，审核员可审核状态变更，管理员全权管理）。
（类比：状态机就像交通信号灯，不同操作（如“按下按钮”）触发状态变化（如从“红灯”变“绿灯”），操作日志记录每个状态变化的原因。）
3) 【对比与适用场景】
| 模块/表 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 状态机表 | 定义实体状态与转换规则 | 存储状态（如货物状态：待装/已装）、转换条件（JSONB） | 管理货物/船舶状态逻辑 | 需明确状态转换的触发条件，避免逻辑冲突 |
| 操作日志表 | 记录操作行为与状态变更 | 包含操作ID（UUID）、时间戳、操作人、内容、实体ID、当前状态、状态变更JSON | 船代日常操作（如货物装卸、船舶靠泊） | 状态变更字段需记录前状态与触发操作ID，确保可追溯 |
| 关联单证表 | 存储提单、装箱单等单证 | 单证ID、类型、内容（JSONB）、版本号、修改日志 | 关联操作与单证，支持变更追溯 | 单证内容用JSONB，添加版本号与修改记录，同步状态变更 |
| 权限控制表 | 角色与权限映射 | 角色ID、名称、权限（增删改查、操作记录、审核） | 系统权限管理 | 通过外键或业务逻辑校验权限，避免权限滥用 |
| 操作员 vs 审核员 | 权限差异 | 操作员：提交自身操作、查看日志；审核员：审核状态、查看审核日志 | 现场操作员（记录操作）与管理层（审核） | 操作员不能修改他人日志，审核员不能记录操作，通过数据库约束或逻辑实现 |
4) 【示例】
伪代码（插入操作日志，包含状态变更）：
POST /api/logs
{
"operation_id": "LOG-20240510-001",
"timestamp": "2024-05-10 14:30:00",
"operator": "操作员A",
"operation_content": "完成集装箱C001的装卸",
"vessel_id": "V001",
"cargo_id": "C001",
"current_status": "已装",
"status_change": {
"from": "待装",
"to": "已装",
"change_time": "2024-05-10 14:30:00",
"trigger_operation_id": "LOG-20240510-001"
},
"related_documents": [
{
"doc_id": "B/L-12345",
"doc_type": "提单",
"content": {
"version": 1,
"modify_log": []
}
}
]
}
数据表SQL（状态机与操作日志）：
-- 状态机表
CREATE TABLE status_machine (
entity_type VARCHAR(20) PRIMARY KEY, -- 船舶/货物
state VARCHAR(20) PRIMARY KEY, -- 当前状态
transition_rules JSONB NOT NULL -- 转换条件，如 {"from": "待装", "action": "装卸", "to": "已装"}
);
-- 操作日志表
CREATE TABLE operation_log (
operation_id VARCHAR(50) PRIMARY KEY,
timestamp DATETIME NOT NULL,
operator VARCHAR(50) NOT NULL,
operation_content TEXT NOT NULL,
entity_type VARCHAR(20),
entity_id VARCHAR(20),
current_status VARCHAR(20),
status_change JSONB,
related_documents JSONB,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
5) 【面试口播版答案】
面试官您好，我设计的船代现场操作日志系统核心是通过状态机管理货物和船舶的状态变更，结合消息队列保证日志实时性，并采用角色权限分级控制。系统包含三个核心功能：一是状态跟踪，用状态机表定义状态（如货物“待装”“已装”），操作触发状态转换（如装卸操作使状态从“待装”变“已装”），操作日志记录状态变更；二是操作记录，记录具体操作（如货物起吊、船舶靠泊），关键字段包括操作ID（UUID）、时间、操作人、内容、关联实体（船舶/货物ID）；三是审计追溯，支持按时间、船舶、操作人查询，保留状态变更历史。权限控制上，分为管理员（全权限，管理角色与状态机）、操作员（仅能提交自身操作，查看自身日志）、审核员（仅能审核状态变更，不能修改操作内容），通过角色-权限映射表实现，操作员与审核员的权限通过数据库外键约束（如操作员表与日志表关联）或业务逻辑校验。比如，操作员提交日志后，审核员只能修改审核状态（如“通过”），不能修改操作内容。系统采用消息队列（如RabbitMQ），操作员提交日志后，消息队列异步写入日志表，通过确认机制（ACK）确保消息不丢失，死信队列处理未确认消息，保证日志实时性与可靠性。这样既能满足现场操作记录需求，又能通过状态机与权限控制保障数据安全与审计追溯。
6) 【追问清单】
- 问题1：系统如何处理状态转换的异常（如操作员提交错误状态变更？）
回答要点：审核员在审核时标记异常，操作员可修改日志，管理员可查看异常记录，确保状态变更的准确性。 - 问题2：消息队列的死信队列如何配置？延迟时间和重试策略？
回答要点：死信队列延迟时间设为5分钟，重试次数3次，超过则移入死信队列，管理员可手动重试或人工干预。 - 问题3：操作日志中的状态变更记录如何与关联单证同步？
回答要点：关联单证表记录单证版本，操作日志中的状态变更触发单证版本更新，确保单证与状态一致。 - 问题4：跨部门（如财务）如何共享特定状态（如“已装”）的日志？
回答要点：通过API接口提供状态查询服务，财务部门通过授权访问，筛选“已装”状态的货物日志，系统支持按状态、实体ID等维度筛选。 - 问题5：状态机表如何维护？新增状态或转换规则时如何更新？
回答要点：管理员通过管理后台更新状态机表，系统验证转换规则的有效性，确保状态转换逻辑正确。
7) 【常见坑/雷区】
- 坑1：状态机表未定义状态转换规则，导致状态变更逻辑混乱，操作员无法正确触发状态变化。
- 坑2：消息队列未配置死信队列，高并发下未确认消息导致日志丢失。
- 坑3：权限控制未区分审核员与操作员的实际权限（如审核员能修改操作内容），导致数据篡改。
- 坑4：操作日志未记录状态变更的触发操作ID，无法追溯状态变更的来源。
- 坑5：关联单证表未添加状态同步字段，导致单证与操作日志状态不一致，影响审计。