逝者已矣手写完整示例：3步调通复制代码
刚把网上抄的“逝者已矣”逻辑扔进工程里，直接报空指针。别慌，这种复制来的代码跑不通不知道怎么调的情况太常见了。很多人卡在变量作用域和生命周期上，以为逻辑通就行，结果运行时崩了。今天咱们不整虚的，直接给一份能跑通的完整示例，把那些坑一个个填平。
入口定位：为什么你的代码会崩
很多兄弟拿到一段处理“结束状态”的代码，比如项目结项、数据归档，看着逻辑挺顺：先查状态，再删数据，最后通知用户。代码跑两遍就报错，甚至数据库锁死。
问题出在哪？出在状态同步。你查到的状态是旧的，删数据时状态已经变了，或者并发请求同时进来，导致数据不一致。这在多线程环境下是致命的。Stack Overflow 上有大量关于 ConcurrentModificationException 和死锁的讨论，核心原因都是缺乏原子性操作。
很多人忽略了一个细节：“逝者已矣”不仅仅是一个动作，而是一个状态变迁过程。从“活跃”到“死亡”，中间有过渡态。如果你的代码没有处理这个过渡态，就像两个人同时抢一把椅子，最后椅子碎了。
核心片段：拆解关键源码
我们来看一段典型的错误写法，以及修正后的核心逻辑。
错误示范：非原子操作
// 错误：检查与操作分离，存在时间窗口
public void terminateProject(Long projectId) {// 1. 查询状态Project project = projectMapper.selectById(projectId);if (project.getStatus() == ProjectStatus.ACTIVE) {// 2. 这里如果发生并发，状态可能已被其他线程修改// 3. 直接删除，没有乐观锁保护projectMapper.deleteById(projectId);// 4. 发送通知messageService.send(Project Terminated, projectId);}
}逐行注释解析：selectById 查出来的状态是 T0 时刻的。
如果 T0 到 T1 时刻，另一个线程把状态改成了 TERMINATING 或 TERMINATED。
当前线程依然执行 deleteById，导致数据被意外删除，或者通知发送给了已不存在的状态。
没有版本号校验，无法感知状态变化。正确写法：乐观锁 + 状态机
// 正确：使用乐观锁确保原子性
@Transactional
public Result terminateProject(Long projectId) {// 1. 查询最新状态及版本号Project project = projectMapper.selectForUpdate(projectId);if (project == null) {return Result.error(Project not found);}// 2. 状态校验：只有 ACTIVE 才能转为 TERMINATEDif (project.getStatus() != ProjectStatus.ACTIVE) {return Result.error(Invalid status transition: + project.getStatus());}// 3. 核心：更新状态时带上版本号条件// SQL: UPDATE project SET status=TERMINATED, version=version+1 // WHERE id=#{id} AND version=#{oldVersion}int rows = projectMapper.updateStatusWithVersion(projectId, ProjectStatus.TERMINATED, project.getVersion());if (rows == 0) {// 4. 更新失败，说明版本冲突，抛出异常触发重试或返回提示throw new OptimisticLockException(Concurrent modification detected);}// 5. 事务提交后，再发送非关键路径通知（或放入消息队列）eventPublisher.publishEvent(new ProjectTerminatedEvent(projectId));return Result.success();
}逐行注释解析：selectForUpdate：加行锁，防止查询期间数据被改（高并发场景下可优化为不加锁，靠版本号兜底）。
status != ACTIVE：严格的状态机校验，杜绝非法跳转。
updateStatusWithVersion：这是灵魂。SQL 里带了 AND version=#{oldVersion}。如果版本号变了，rows 就是 0，说明有人比你先改了。
rows == 0 抛异常：触发事务回滚，保证数据一致性。
publishEvent：解耦通知逻辑，避免慢查询阻塞主流程。设计思想：状态机与幂等性
这段代码背后的设计思想，其实是有限状态机（FSM）。
“逝者已矣”对应的是状态从 ACTIVE 到 TERMINATED 的单向流转。一旦进入 TERMINATED，就不能再变回 ACTIVE（除非你做了“复活”功能，那是另一个故事）。
为什么强调幂等性？
用户手抖点了两次“结束项目”。第一次成功，状态变 TERMINATED。第二次请求进来，查状态发现不是 ACTIVE，直接返回错误“状态非法”。这就是幂等。如果没有这个校验，第二次请求可能会重复删除数据，或者重复发送通知，导致用户困惑。
乐观锁 vs 悲观锁：悲观锁（select for update）：像排队上厕所，进去之前把门锁上，别人等着。适合写操作多、冲突少的场景。
乐观锁（version）：像抢票，不锁票，提交时检查票还在不在。适合读多写少、高并发场景。
在“结束项目”这种低频但关键的操作中，乐观锁 + 事务 是更优雅的选择。它避免了长时间持锁导致的数据库连接池耗尽。手写简化版：Go 语言实现
如果你用 Go，逻辑类似，但并发模型不同。这里给一个简化的 Handler 示例，重点看互斥锁和状态检查。
package handlerimport (syncerrorscontext
)type Project struct {ID int64Status stringVersion int64mu sync.Mutex // 注意：在生产环境中，不要直接在结构体里放 Mutex，应该用 Map 或分布式锁
}type Service struct {projects map[int64]*Project
}func (s *Service) Terminate(ctx context.Context, id int64) error {// 1. 获取项目p, exists := s.projects[id]if !exists {return errors.New(project not found)}// 2. 加锁，保证检查-更新原子性p.mu.Lock()defer p.mu.Unlock()// 3. 状态检查if p.Status != ACTIVE {return errors.New(invalid status: + p.Status)}// 4. 更新状态p.Status = TERMINATEDp.Version++// 5. 异步通知（示意）go func() {// 发送消息}()return nil
}关键点：sync.Mutex：在单实例内存中，这是最简单的并发控制。
生产环境警告：Go 的 Mutex 不能跨实例共享。如果是分布式系统，必须用 Redis 分布式锁或数据库乐观锁。上面的 Java 代码里的 version 字段，在 Go 里同样适用，配合 gorm 或 sqlx 的 Where(version = ?, oldVersion)。
上下文取消：ctx 传入，方便超时控制。应用场景：公路工程中的“项目结项”
别觉得这是互联网的黑话，公路工程里到处都是这种“逝者已矣”的场景。
场景一：标段完工验收
一个高速公路标段，施工方提交完工报告。监理审核通过，业主确认。这时候，标段状态从“施工中”变为“已完工”。痛点：财务、审计、工程部同时操作。财务要付款，审计要查账，工程部要归档。
违规风险：如果状态变更不原子，可能导致“钱付了但状态没变”，或者“状态变了但发票没入账”。
应用：用状态机严格管控。只有 ACCEPTED 状态才能触发 PAYMENT_REQUEST。任何环节的状态不一致，都要通过版本号或事务回滚来保证。场景二：资质与人员绑定
建造师注册在某个项目上，项目结束了，人得解绑。痛点：人员调动频繁。A 项目结束，B 项目开始。如果解绑和绑定没做好原子性，可能出现“一人挂多证”或“证书悬空”的违规问题。
应用：人员与项目的绑定关系，要有唯一性约束。项目状态变为 TERMINATED 时，自动触发解绑事务。如果解绑失败（比如新项目还没开始），整个结项流程应该回滚或挂起，不能强行结束。报考学历与工作年限要求：
很多想进这个领域的兄弟，问报考要求。以一级建造师为例，工程类或工程经济类专业，本科需 4 年工作经验，大专需 6 年。这里的关键是**“从事建设工程项目施工管理工作满 X 年”**。注意：工作年限是累计的，不要求连续。但必须是“施工管理”相关。
现场常见违规：很多工地为了凑人数，把资料员、安全员都算进施工管理年限。这在审计时是高风险点。系统里如果记录的人员角色与报考要求不符，可能影响证书有效性。
系统支持：你的项目管理系统，必须能准确记录每个人员的岗位角色和进场/退场时间。当项目“逝者已矣”时，系统要能生成精确的工作年限证明，而不是模糊的“参与过”。结尾互动
代码调通了，逻辑顺了，但现实中的坑还在。
你更常用哪种写法？是数据库乐观锁，还是 Redis 分布式锁？在高并发的“项目结项”场景下，你是选择强一致性（牺牲性能），还是最终一致性（允许短暂不一致）？
评论区交流，说说你在现场遇到的最离谱的状态不一致问题。
