2026 年技术总结
每年写一篇技术总结，是给自己的交代，也是给同行者的参考。这是第一年的思考。 一、技术深度 vs 广度的平衡 1.1 今年的侧重——在框架和中间件上深挖 1.2 明年想扩展——AI 和云原生 二、业务理解的重要性 2.1 技术不能脱离业务——今年最大的感悟 2.2 一个技术决策背后的业务考量 三、团队与技术管理 3.1 从写代码到指导写代码——角色的转变 3.2 技术债务的管理——砍不砍的平衡 四、AI 对开发者的影响 4.1 AI 辅助编程——效率提升还是代码质量下降？ 4.2 不被替代的核心能力——系统设计、业务理解 五、明年的技术方向 5.1 AI 工程化——把 AI 接...
跨团队项目的推动与落地实践
第一次做技术 PM，推动一个涉及 3 个团队的项目。踩过的坑、学到的经验都在这里。 一、技术 PM 的职责定位 1.1 不是项目经理——更关注技术决策 1.2 核心职责——方案设计 + 进度推进 + 风险识别 1.3 技术 PM 的画像——技术过硬 + 沟通顺畅 + 有责任心 二、项目启动——对齐目标 2.1 明确 why ——业务价值和成功标准 2.2 识别干系人——谁参与、谁决策、谁受影响 2.3 召开 Kickoff——统一目标和分工 三、方案设计——技术先行 3.1 整体架构设计——各团队的边界和接口 3.2 接口定义优先——契约先行 3.3 风险预案——识别关键路径和瓶...
P6 与 P7 高级工程师能力模型差异
P6 到 P7 的晋升，不只是技术变强了——是思维方式和工作模式的根本转变。 一、P6 的核心能力 1.1 独立负责一个模块——从需求到上线 1.2 技术深度——能解决复杂的技术问题 1.3 代码质量——写出可维护的高质量代码 1.4 典型的 P6——“我能把这个功能做好” 二、P7 的核心差异 2.1 从”做好一件事”到”带着别人做好几件事” 2.2 技术广度——跨领域的技术方案设计 2.3 技术规划——未来 3-6 个月要做什么 2.4 影响力——影响团队的技术决策 2.5 典型的 P7——“我来设计怎么做，并带着团队做出来” 三、能力模型对比 3.1 技术能力——深度 P6...
全链路压测后的线上故障复盘
压测 QPS 到 5 万，实际峰值才 3 万，服务却挂了。压测不等同于真实流量——复盘 5 个经典的压测盲区。 一、问题背景 1.1 压测结果——全链路压测 5 万 QPS，99 分位 RT 正常 1.2 实际情况——峰值 3 万 QPS，多个服务超时 1.3 现象——数据库 CPU 100%，连接池耗尽 二、盲区 1：压测数据分布不均 2.1 压测数据——均匀分布，每个用户访问量差不多 2.2 真实数据——20% 的热点用户产生 80% 的请求 2.3 热点用户导致热点 Key（Redis）/ 热点行（DB） 2.4 改进——压测数据模拟真实分布（长尾分布） 三、盲区...
工作中常用的数据结构和算法
刷了几百道 LeetCode，工作时却很少用到？现实中真正有用的算法和数据结构有哪些？ 一、跳表——Redis ZSet 的核心 1.1 为什么 Redis 用跳表而不是红黑树 1.2 跳表的结构——多层索引 1.3 插入/查找的时间复杂度 二、布隆过滤器——缓存穿透克星 2.1 判断”一定不存在” 2.2 应用——防止缓存穿透、URL 去重 2.3 Guava BloomFilter 的使用 2.4 误判率与 bit 数组大小 三、一致性哈希——分布式缓存的路由 3.1 取模分片的扩容问题 3.2 哈希环 + 虚拟节点 3.3 应用——Dubbo 负载均衡、Redis...
线上 OOM 故障排查
凌晨收到告警：服务频繁重启。登录发现 OOM Killer 杀了 Java 进程。本文是完整的排查和修复复盘。 一、告警与发现 1.1 监控告警——服务重启次数陡增 1.2 第一时间确认——dmesg | grep -i kill，OOM Killer 1.3 临时止血——重启服务，增加内存（-Xmx 调大） 二、保留现场 2.1 GC 日志——-Xlog:gc* 输出 2.2 堆 dump——-XX:+HeapDumpOnOutOfMemoryError 2.3 线程 dump——jstack 2.4 系统指标——CPU、内存趋势 三、GC 日志分析 3.1 Full GC 频...
技术方案评审模板与写作方法
写技术方案是高级工程师的核心能力之一。好的方案让评审人一看就懂，坏方案让人看完满脑子问号。 一、方案的受众分析 1.1 你的方案给谁看——Tech Lead / 架构师 / 同级开发 / 产品经理 1.2 不同角色关注什么——架构师看设计，开发看实现，产品看影响 二、方案结构模板 2.1 背景与目标——为什么要做，解决什么问题 2.2 业界调研——别人怎么做的，有什么参考 2.3 方案设计——核心思路、架构图、流程图 2.4 方案对比——与备选方案的优劣分析 2.5 详细设计——数据库设计、接口设计、关键流程 2.6 风险评估——技术风险、业务风险、应...
技术选型框架与实践
技术选型不能凭”谁火用谁”。本文给出一套可复用的选型框架，以消息队列选型为例演练。 一、选型的五维模型 1.1 功能维度——是否满足业务需求 1.2 性能维度——吞吐量、延迟、容量 1.3 运维维度——部署、监控、升级 1.4 团队维度——学习成本、现有经验 1.5 生态维度——社区活跃度、工具链 二、功能维度分析 2.1 消息模型——点对点 / 发布订阅 / 广播 2.2 消息顺序——全局有序 / 分区有序 2.3 消息可靠性——持久化、ACK 机制 2.4 事务消息——分布式事务支持 2.5 延时消息——定时投递 2.6 Kafka / ...
DDD 在电商订单域的实践
DDD 不是银弹，但在复杂业务域中它确实能帮你理清边界。以电商订单域为例，从战略设计到战术设计完整落地。 一、DDD 核心概念速览 1.1 战略设计——限界上下文、上下文映射 1.2 战术设计——聚合、实体、值对象、领域服务、仓储 1.3 领域事件——事件驱动 二、战略设计——事件风暴 2.1 识别领域事件——“订单已创建”、”订单已支付”、”订单已发货” 2.2 识别命令——“创建订单”、”支付订单” 2.3 识别聚合——Order 聚合、Product 聚合 2.4 划定限界上下文——订单上下文、商品上下文、支付上下文、用户上下文 三、上下文映射 3.1 订单上下文 ↔ 商品...