一、先把问题看清楚：危机感到底从哪来

很多人把 35+ 的焦虑简单归结为“年龄歧视”，这只说对了一部分。把视角拉高，你会发现危机感来自三个结构性变化的叠加：

1. 供给端：每年都有大量计算机相关专业毕业生进入市场，初级岗位竞争长期处于高位。企业招一个“能写业务代码的开发”的门槛越来越低，而这类岗位的可替代性天然就高。
2. 需求端：行业从“快速建设期”进入“存量运营期”。新系统、新模块的开发需求收缩，更多工作是维护、小改、对接，这在体感上就是“新需求越来越少”。
3. 成本端：工作十年以上的工程师，薪资水平通常显著高于新人。当产出的“不可替代性”没有同步拉开差距时，企业在成本压力下首先审视的就是这一段人力。

理解了这三点，就能得出一个重要结论：焦虑不是你个人的失败，而是市场给你的理性信号，它提示你当前的技能组合与市场需求出现了错配。信号本身是中性的，关键在于你如何响应。

二、客观盘点：CRUD 背后你到底拥有什么

长期做业务系统的工程师，很容易自我贬低为“只会 CRUD”。这个判断既不准确，也不公平。建议用一张清单冷静盘点：

你已经拥有的资产：

• 业务上下文：你熟悉一个业务域的来龙去脉，知道坑在哪里，新人需要半年才能建立的认知你已积累多年；
• 稳定性经验：维护老项目意味着你处理过线上故障、脏数据、历史包袱，这是很多只在全新项目里工作过的人不具备的能力；
• 交付习惯：接口对接、报表开发锻炼的是把模糊需求落地的工程能力。

通常欠缺的部分：

• 技术深度（虚拟机、并发、存储层面的原理性理解）；
• 架构视野（从模块设计到跨系统设计）；
• 对外可见的影响力（技术输出、带人经验）。

盘点的意义在于：你的转型不需要从零开始，而是要把现有资产与稀缺能力嫁接起来。

三、35+ 同行的真实去向

基于行业普遍观察，35 岁以上的后端工程师大致流向以下几条路径。没有哪条绝对正确，只有与你个人资产匹配度的差异：

路径一：技术专家。 深耕一个纵向领域：性能调优、高并发、稳定性工程、数据一致性等。这条路线要求你把某个点打穿到原理层，而不是停留在“会用”。

路径二：架构师。 从“把代码写对”升级为“把系统设计对”。架构能力不是头衔给的，而是由一次次设计权衡、技术选型、故障复盘堆出来的。

路径三：领域专家。 深耕某个行业的业务与系统，成为“懂业务的技术人”。这类人在行业内非常稀缺，年龄反而是加分的资历。

路径四：技术管理。 带团队、管项目，本质是换一个杠杆发力，要求你补齐沟通、规划、向上管理等软技能。

路径五：泛技术岗位。 解决方案、交付实施、技术咨询等岗位，看重技术背景与表达能力，对年龄相对宽容。

路径六：独立开发与自由职业。 依托积累做小型产品、接项目、做技术内容，收入不稳定但自由度高，适合有储备的人。

路径七：进入更稳定的组织。 部分人选择进入体制内、国企或传统行业的信息化部门，用收入预期的下降换取职业周期的延长。

值得注意的是：前四条路径都要求你比现在“更深”或“更宽”，没有一条是靠原地踏步就能走通的。

四、能力升级的具体路径：从今晚就能做的事开始

1. 把技术深度打穿：以一次接口优化为例

性能优化是最容易建立正反馈的深水区。假设你手上有一个报表接口，响应时间 3 秒，优化过程大致如下：

第一步，定位瓶颈。通过日志与采样确认时间花在数据库往返上，典型原因是循环内逐条查询：

// 优化前：N+1 查询，每条记录触发一次数据库往返
for (Order order : orders) {
    order.setUser(userDao.findById(order.getUserId()));
}

第二步，改为批量拉取，把 N 次往返压缩为 1 次：

// 优化后：一次批量查询，内存中完成组装
Set<Long> userIds = orders.stream()
        .map(Order::getUserId).collect(Collectors.toSet());
Map<Long, User> userMap = userDao.findByIds(userIds).stream()
        .collect(Collectors.toMap(User::getId, u -> u));
orders.forEach(o -> o.setUser(userMap.get(o.getUserId())));

第三步，引入缓存与异步：热点维度数据放入缓存，非实时的统计计算改为定时任务预计算，接口只读结果。

一个这样的完整案例，如果你能讲清楚“现象—定位—假设—验证—收益”的全过程，在面试和技术评审中的说服力，远超简历上“熟悉高并发”五个字。

2. 从写代码到设计系统：补架构能力

不必等待“被任命为架构师”才开始练习。可以从三件小事做起：

• 给自己负责的模块画出依赖图，识别循环依赖与不合理分层；
• 在评审他人方案时，练习追问“这个设计的失效场景是什么”；
• 用演进式思路改造老系统，而不是幻想推倒重来。

示意一个常见的分层改造，把“业务逻辑直接读写数据库”的代码，重构为职责清晰的分层结构：

// 优化前：校验、扣库存、写订单、发通知全部堆在一个方法里
public void placeOrder(OrderRequest req) { /* 数百行混合逻辑 */ }
// 优化后：应用层只编排，领域逻辑下沉
public OrderResult placeOrder(PlaceOrderCommand cmd) {
    Order order = orderFactory.create(cmd);      // 领域对象
    inventoryService.deduct(order);              // 库存领域服务
    orderRepository.save(order);                 // 持久化收口
    eventPublisher.publish(order.toEvent());     // 领域事件解耦后续动作
    return OrderResult.of(order);
}

架构能力的本质是控制复杂度的能力，只能通过反复的设计实践获得。

3. 提升工程效率与可观测性意识

存量系统的价值很大程度体现在“可维护性”上。主动推动以下事情，会显著提升你的不可替代性：

• 建立规范化的日志、指标与告警体系（对应日志服务、监控告警等通用能力类目）；
• 把重复劳动脚本化、自动化，接入持续集成流程；
• 沉淀文档：系统架构图、故障处理手册、新人上手指南。

这些工作在平静时期不显眼，但每一次线上故障，都是它们的价值兑现时刻。

4. 建立对外可见的技术资产

• 坚持写技术复盘，哪怕只有自己可见，梳理清楚也比模糊记得强；
• 在团队内做技术分享，锻炼结构化表达；
• 长期尝试公开输出，逐步积累个人信誉与行业连接。

五、职业风险管理：技术之外的必修课

1. 财务安全垫：按家庭支出预留 6～12 个月的现金储备，它决定你面对变化时是“从容选择”还是“被迫接受”。
2. 保持市场敏感：即使不打算跳槽，也建议每年更新简历、参加一两次面试，校准自己在市场中的真实位置。
3. 维护同侪网络：35+ 的机会大量来自熟人推荐而非公开投递，平时靠谱的交付就是人脉账户里的存款。
4. 管理精力与心态：规律作息与持续运动不是鸡汤，而是长周期职业竞争的基础设施。

六、写在最后

“写代码这件事我其实不讨厌”，这句话其实是最宝贵的资产。职业中期的破局，从来不是抛弃过去另起炉灶，而是把十几年的业务积累、系统经验，嫁接到更深的技术能力和更宽的视野上。

35+ 的竞争逻辑和 25 岁不同：年轻人拼学习速度，你拼的是判断力、稳定性与解决问题的完整度。新需求变少不可怕，可怕的是在等待中放弃进化。从今晚复盘一个线上问题、明天重构一个混乱模块开始，用可积累的小动作对抗不确定的大环境，这才是对“还能干多久”这个问题最有力量的回答。