高并发设计
从限流、熔断到缓存击穿防护，构建能扛住流量峰值的后端系统，而不是只会写 CRUD。
- 接口幂等与防重设计
- 多级缓存与热点数据治理
- 异步化与消息队列削峰
技术星图
不是技能标签的堆叠，而是一套在真实生产环境里跑通的完整工程体系。 五个域互相咬合，形成从需求到上线的闭环。
think
ENGINEER
工程实力
工程能力的衡量标准不在于会写多少 API，而在于系统跑得多稳、响应得多快、故障时能不能兜住。
API 网关
响应时间
0
P99 延迟 — 核心交易链路
数据库
查询耗时
0.02s
索引命中率
99.4%
缓存命中率
96.8%
连接池
HikariCP / 50
部署
docker
api-service
运行中
docker
redis-cache
运行中
docker
mysql-primary
运行中
docker
nginx-gateway
运行中
能力评估
系统架构
用微服务拆分复杂度，以服务边界和数据边界为依据，让代码库在规模增长时依然可控。
- Spring Cloud 服务治理
- 分布式事务与一致性
- 链路追踪与故障定位
部署运维
具备从代码到生产环境的完整交付能力，上线不是终点，可观测与持续迭代才是。
- Linux 环境独立部署
- Docker 容器化编排
- 线上问题排查与止血
数据与缓存
理解数据本身才是性能的根，SQL 优化、索引设计与缓存策略一起看，才知道瓶颈在哪。
- 慢查询定位与优化
- 索引设计与表结构治理
- Redis 多级缓存设计
代码实验室
真的可以跑。MySQL 里存着我的完整档案 —— 直接执行一条 SELECT 就能读出来。
developer.sql
1-- 一条 SQL，读完整个人的技术档案
2SELECT *
3FROM developer
4WHERE username = 'think';
5
6-- index: idx_username (UNIQUE)
7-- engine: InnoDB charset: utf8mb4查询结果
// 点击「查询」读取 developer 表
Main.java
1public class Main {
2
3 public static void main(String[] args) {
4 System.out.println("Hello Think");
5 }
6
7 static void stackTrace() {
8 System.out.println("Engineer mindset");
9 }
10
11 static void ship() {
12 new SpringApplication(Main.class).run(args);
13 }
14}输出
// 点击运行执行
redis-cli
1# 同一份数据，走缓存和走数据库的差别
2127.0.0.1:6379> GET developer:think
3
4# 第一次：缓存未命中，回源 MySQL
5# 第二次：缓存命中，直接返回
6
7127.0.0.1:6379> SETEX developer:think 3600 {...}
8127.0.0.1:6379> TTL developer:think缓存命中
// 点击「执行」查看缓存命中演示
docker-compose.yml
1version: "3.9"
2services:
3 api-service:
4 image: think/api:1.0.0
5 ports:
6 - "8080:8080"
7 depends_on:
8 - redis-cache
9 - mysql-primary部署日志
// 点击「启动」拉起服务
项目实验室
每个项目都不是一个静态页面。这里展示的是架构决策、踩过的坑，以及最终跑出来的数字。
9:41100%
发现
电商小程序全栈系统
从 0 到 1 的完整交付。前端小程序 + Java 微服务后端，覆盖商品、订单、支付、履约全链路。 日订单峰值 12 万，全链路 P99 响应控制在 80ms 以内。
技术难点
- 秒杀场景下的超卖与库存一致性
- 订单状态机与分布式事务
- 小程序首屏加载与弱网体验
解决方案
- Redis 分布式锁 + 库存预扣，异步落库
- 状态机枚举约束 + 定时任务对账补偿
- 分包加载 + 接口聚合，减少首屏请求数
12万日订单峰值
80msP99 响应
99.98%可用性
企业数据中台
面向内部运营团队的数据平台，整合多业务线数据源，提供统一看板与自助分析。服务 200+ 内部用户，日均查询 3 万次，慢查询从 2.3s 优化到 120ms。
技术难点
- 多数据源异构结构统一建模
- 大批量聚合查询的响应瓶颈
- 看板配置的动态化能力
解决方案
- 元数据驱动的通用查询引擎
- 物化视图 + 结果缓存分层
- 配置化看板，拖拽即生成 SQL
95%↓查询耗时下降
3万日均查询
0.8s报表生成
INPUT需求描述
AGENT任务拆解
OUTPUT代码 / 文档
AI 研发效能工作流
把 AI 接入到真实的研发流程里，而不是停留在聊天窗口。围绕需求、编码、测试、文档四个环节构建 Agent 工作流，团队需求交付周期缩短 35%。
技术难点
- AI 输出不稳定，需可控可复现
- 上下文管理，超长代码库检索
- 与现有工程体系集成
解决方案
- 结构化 Prompt 模板 + 校验重试
- 向量检索 + 分层摘要压缩上下文
- 以 CLI / Hook 形式嵌入研发流程
35%↓交付周期
4环节覆盖
10+复用 Agent
AI 工程实践
AI 不是替代工程师的按钮，而是一层新的工具栈。关键在于怎么把它编排进既有流程。
01
Prompt 工程
把模糊需求翻译成模型能稳定执行的结构化指令。角色、约束、示例、输出格式，四要素缺一不可。
02
AI Agent
让模型能自己调用工具、读文件、跑命令。单次对话是问答，Agent 才是真正能落地干活。
03
AI 工作流
单个 Prompt 的价值有限。把 AI 编排成流水线，接进 Git、CI、文档流程，才产生复利。
04
AI 辅助开发
日常用 AI 补测试、写脚本、查文档、读陌生代码。工具用得好，工程师的产出翻倍。
关于我
一个持续探索技术边界的开发者。
从后端服务，到前端体验，从服务器部署，到 AI 工程实践。我关心的不只是代码能不能跑起来，而是它在真实环境里是否稳定、是否可维护、是否经得起放量。
我的技术底色是 Java 后端 —— Spring Boot、Spring Cloud、微服务、分布式系统。在这个基础上向外延伸：前端能独立完成完整界面，Python 能写自动化工具打通流程，AI 方向则在探索如何真正提升软件工程效率。
我相信好的工程不只是把功能实现出来，而是让系统在半年后依然好维护。
01
软件工程效率
用工具和流程减少重复劳动，把时间还给真正需要思考的部分。
02
系统稳定性
稳定性不是不出故障，而是出故障时能快速定位、快速恢复。
03
技术创新
持续跟进新工具与新范式，但始终以真实收益为判断标准。
think
全栈开发者 / 后端工程师
核心方向Java 后端 / 分布式系统
前端能力Vue2 / Vue3 / 工程化
扩展方向Python / AI 工程
交付方式Docker / Linux 部署