React 前端工程师 · 上海 · 5 年经验
xuzhixing@example.com · 137 0000 0000 · github.com/xuzhixing
个人优势
- 5 年 React 经验，长期维护高流量下单链路和商家工作台，习惯从用户指标、性能数据和故障记录反推技术优先级
- 熟悉 React 18 并发渲染、Suspense、Hooks 闭包与依赖问题，排查过重复渲染、Context 更新过宽和水合不一致
- 性能治理按真实用户 P75 指标验收：下单页 LCP 从 3.2 秒降到 1.9 秒，提交率提升约 1.4 个百分点
- 状态管理有清晰的分层：服务端数据用 TanStack Query，跨页状态用 Zustand，表单草稿留在组件内
- 处理过金额和并发一致性问题：价格计算收进纯函数、服务端为准、乐观更新带版本号冲突检测
- 做过大规模表单：规格矩阵分块计算，300 个规格组合下输入延迟控制在 80ms 以内
- 有测试与发布的工程习惯：主链路 Playwright 冒烟测试跑在灰度环境，拦下过两次接口字段变更
- 建过团队内部的性能排查工具，把 React Profiler 和 Performance 长任务对照，用于 9 次性能专项评审
- 熟悉 Next.js App Router 与 RSC 的边界，做过商家帮助中心的 SSR 改造
- 在 6 人小组承担方案设计和代码评审，能把性能预算、回归用例和发布检查落到日常流程
- 技术栈：React、TypeScript、Zustand、Redux Toolkit、TanStack Query、Vite、Webpack、Vitest、Playwright
工作经历
某城市生活平台 · React 前端工程师
交易前端组负责商家工作台和用户下单链路，前端 6 人；工作台约 1.6 万日活商家，下单高峰会集中在午晚餐时段。
- 下单页性能：和产品确定先看移动端 P75 LCP 与提交转化率。通过真实用户监控定位到首屏图片、同步地图 SDK 与过大的公共包；图片改分辨率自适应，地图移到选择地址后加载，公共包按路由拆分。灰度一个月后 LCP 从 3.2 秒降到 1.9 秒，提交率提升约 1.4 个百分点
- 购物车状态：原先活动价和满减价由三个组件各自计算，切换门店时偶发金额不一致。把价格计算收进纯函数，服务端价格为最终值，前端只展示预估；补齐跨店、券失效和并发加购用例，相关客服工单从每周十余件降到 2 件以内
- 商家表单：把营业时间、配送范围和商品规格三个高频表单的字段协议统一，复杂联动仍由业务组件处理，避免把所有逻辑塞进一个万能引擎。新门店开通流程从 14 个页面收敛到 8 个步骤，平均填写耗时降低约四成
- 发布质量：为下单主链路补 Playwright 冒烟测试，覆盖地址、优惠券、支付回跳与重试。测试在灰度环境运行，发现两次接口字段变更后才推进全量；上线后季度内没有重复出现支付状态丢失问题
某企业服务公司 · 前端开发工程师
公司面向连锁零售企业提供库存与订货系统，前端团队 4 人，我负责订货工作台和公共组件。
- 订单列表原来一次渲染数百行且每行有多个 Popover。用虚拟列表仅渲染可视区域，弹层挂到统一容器，并对筛选条件做 URL 持久化；低配办公电脑上的筛选响应从约 900ms 降到 200ms
- 建立组件库的版本发布流程：变更说明、示例页、视觉回归和废弃期。推动 12 个页面从复制粘贴的表格代码迁到同一套列配置，后续修复固定列错位只需改一处
- 配合后端梳理导出任务：大文件导出改成提交任务、轮询状态、完成后下载，失败显示可重试原因。减少了用户反复点击导致的重复任务
项目经历
商家商品编辑器
React / TypeScript / Zustand / TanStack Query / Vitest
商家可批量编辑价格、库存和多规格商品。此前每个字段失焦即提交，弱网时后返回的旧请求会覆盖新输入；需求由客服和商家运营共同提出。
- 将页面状态分成服务端快照、未提交草稿和校验错误三层。批量保存时携带版本号，遇到冲突让商家选择保留本地或刷新，而不是静默覆盖
- 对规格矩阵使用分块计算，输入一项只更新受影响的 SKU；在 300 个规格组合下，输入延迟由肉眼可见的卡顿降到 80ms 以内
- 保存失败按字段显示原因，成功后再刷新缓存；对价格范围、库存边界和并发冲突写纯函数测试。灰度期间批量编辑的失败工单每周由 20 多件降到个位数
React 组件性能排查工具
React Profiler / Chrome DevTools / TypeScript
团队内部工具，记录业务页面一次交互中的组件提交次数和耗时，帮助新人定位“点一下刷新半屏”的问题。
- 用 Profiler 收集 commit 时长与组件树，按交互名称聚合；和浏览器 Performance 长任务对照，避免只凭 render 次数判断性能
- 给常见问题写可复现示例：不稳定的对象 props、过宽的 Context、昂贵的派生计算。半年内用于 9 次性能专项评审，相关页面的中位交互耗时降低约三成
商家帮助中心 SSR 改造
Next.js App Router / React Server Components / MDX
帮助中心原来是客户端渲染的 SPA，商家在搜索引擎里搜不到答案，只能找客服。
- 文档内容改为 MDX + 服务端组件渲染，目录、相关文章在服务端生成，客户端只保留搜索和反馈两个交互组件，页面 JS 体积减少约 六成
- 文章按更新频率分别使用静态生成和按需再验证，运营改完文档几分钟内上线，不用整站构建
- 上线半年，帮助中心来自搜索的访问量增长到原来的 3 倍左右，「怎么设置营业时间」这类基础咨询明显减少