个人优势

• 4 年 Vue 经验，负责过供应链订货、仓储和教务排课等复杂中台，熟悉业务表单从需求澄清到上线维护的全过程
• 熟悉 Vue 3 响应式、依赖收集和 watch 刷新时机，主导过 400 多个组件从 Vue 2 渐进迁移，期间每周正常发版
• 组件设计讲究边界：通用字段组件只管交互和校验，审批、排课的业务状态机留在各自模块
• 做过扫码枪连续操作场景的性能优化，增量接口 + 批量队列，扫描反馈从约 1 秒降到 200ms
• 权限体系有落地经验：资源码清单由路由、菜单、按钮共用，服务端做最终鉴权，误显示反馈从十多次降到 1 次
• 金额计算统一按「分」做整数运算，修复过多处浮点误差导致的一分钱问题
• 可观测性按影响客户数告警，而不是按错误次数；首次报障到定位从半天缩短到约 20 分钟
• 大数据量计算会移到 Web Worker，补货工作台的交互卡顿从 1.3 秒降到 250ms 左右
• 熟悉 Vite 插件、Vitest、Cypress 和 CI 质量门禁，组件改动配 Storybook 和交互测试
• 重视一线用户的操作时间，会到仓库和客服现场看真实操作，再决定先优化哪一步
• 技术栈：Vue 3、TypeScript、Vite（含插件开发）、Vitest、Cypress、CI 质量门禁

工作经历

产品服务连锁门店的采购、仓储与补货流程，约 500 家企业客户。前端组 5 人，我负责门店订货与仓库管理两条线。

• Vue 3 迁移：老系统 400 多个组件依赖 Vue 2 与 Element UI，业务不能停。先做依赖盘点和兼容测试，保留旧路由并逐模块迁到 Vue 3；把公用 API 适配层单独维护，避免每页散落版本判断。历时 10 周迁完核心模块，期间正常每周发版
• 拣货页效率：仓库员工使用扫码枪连续操作，旧页面每次扫描都重新请求整张单据。和后端约定增量变更接口，前端用批量队列合并短时间扫描结果；100 行订单下扫描反馈由约 1 秒降到 200ms，仓库试点每天少花约半小时核对
• 权限收敛：不同客户的岗位权限配置不一致，按钮权限以前靠页面内散落的条件判断。建立资源码清单，由路由、菜单和按钮共用，服务端仍做最终鉴权；补齐无权限、权限过期和切换租户的用例，季度权限误显示反馈从十多次降到 1 次
• 线上故障治理：接入前端错误和接口耗时监控，将租户、版本和路由写入上下文；按影响客户数而非错误次数报警。定位并修复一个只在旧版安卓扫码浏览器触发的异常，客服首次报障到定位从过去的半天缩短到约 20 分钟

所在 4 人小组维护教务排课和讲师工作台，学期开学前两周访问量明显上升。

• 负责排课日历的拖拽与冲突提示：课程跨校区、教师和教室三个维度验证，前端先给即时反馈，提交时服务端二次校验；排课员需要来回修改的次数减少约三分之一
• 将一批散落的弹窗表单整理为可复用字段组件，但审批和排课使用不同的业务状态机，保留在各自模块，避免共享层吞进业务规则
• 为讲师课表加缓存与离线提示，网络恢复后重新验证最新排课；移动浏览器里的误操作投诉逐月下降

项目经历

Vue 3 / TypeScript / Pinia / ECharts / Web Worker

运营根据过去销量、促销计划和库存水位，为门店生成补货建议。一位运营通常一次审核 30 到 80 家店，页面需要同时展示趋势图和明细表。

• 原来前端在主线程聚合门店与 SKU 数据，切换筛选条件要卡住 1 秒以上。把纯计算移到 Worker，数据按批次发送，图表只更新受影响的序列；普通办公电脑上的交互卡顿从 1.3 秒降到 250ms 左右
• 用 URL 保存筛选维度，审核员复制链接给同事时能打开同一视图；批量采纳建议前展示异常库存与缺失数据，减少误下单
• 联合数据团队给建议值增加来源说明，用户可追溯销量区间、预测版本和人工调整记录。试点客户的“为什么推荐这个数量”咨询量下降约四成

Vue 3 / TypeScript / Storybook / Vitest

为采购、审批和财务页面提供统一的金额、日期、门店选择组件，目标是减少重复实现和边界错误。

• 金额输入统一按“分”做内部整数运算，展示层才转元，修复多处浮点计算造成的一分钱误差
• 门店选择器支持按租户分页搜索、已选项回显和权限变化提示；组件在 18 个页面复用，平均新建业务表单的前端工时由 2 天缩至约 1 天
• 为键盘导航、清空、异步加载失败写交互测试，并在 Storybook 标记不兼容的旧属性，升级时页面可以逐个迁移

Vue 3 / Pinia / WebSocket / IndexedDB

仓库员工用扫码枪连续拣货，一张单子上百行，高峰期每人每小时扫描 600 次以上。

• 扫码枪按键盘输入模拟，连续扫描时字符会串在一起。按输入间隔区分人工输入和扫码，扫码结果进入批量队列，每 100ms 合并提交一次
• 单据改用增量接口，服务端只返回变化的行，前端按行 ID 合并；100 行订单下扫描反馈从约 1 秒降到 200ms
• 仓库网络不稳定，扫描记录先写 IndexedDB，断网时界面显示「待同步」数量，恢复后自动补交，重复扫描由服务端按扫描 ID 去重
• 试点仓库每天核对时间减少约半小时，后续推广到 23 个仓库

教育经历

个人优势

• 5 年数据可视化经验，做过运营看板、城市车辆调度地图和工业三维监控，能区分「数据处理慢」和「绘制慢」两类问题
• 熟悉 ECharts、Canvas、WebGL、Three.js 和 deck.gl，按点位数量、交互方式和设备性能选技术，不为三维而三维
• 大数据量渲染有实战：轨迹按可视区裁剪和像素误差抽稀，数万点只需绘制几百个点
• 熟悉 GPU 拾取、实例化渲染和图层优先级管理，点选延迟保持在 100ms 以内
• 三维性能会从资源入手：和建模同事约定面数、材质和纹理预算，glTF 压缩并按楼层拆包，可交互时间从 12 秒降到 4 秒
• 时序数据做过分层采样：缩小保留每桶最值，放大再取原始数据，几十万点也能快速定位突变
• 有 7×24 小时大屏的稳定性经验：内存泄漏排查、WebGL 上下文丢失恢复、断网状态的明确展示
• 重视数字口径和可读性，和数据工程师对齐指标定义，告警同时用颜色、形状和文字表达
• 做过线上问题的录制回放工具，用同一段数据流复现乱序和坐标异常
• 长期参与现场验收，能处理高 DPI 工控屏、集成显卡和老旧浏览器上的兼容问题
• 技术栈：Canvas 2D、WebGL、Three.js、deck.gl、Mapbox GL、ECharts、React、TypeScript、Web Worker

工作经历

负责城市交通调度系统的地图与指挥大屏。产品接入车辆、路口与事件流，日常在指挥中心连续运行，前端组 5 人。

• 海量点位：旧方案用 DOM 标记车辆，超过 3000 辆时缩放明显掉帧。把静态道路和实时车辆分层，车辆交给 WebGL 实例化绘制，轨迹按视口范围裁剪；一万点位的缩放交互稳定在 45 帧以上
• 实时更新：消息每秒最多几千条，逐条更新图层导致主线程长期满载。服务端改二进制增量包，Worker 中解码并按 200ms 合帧，主线程只提交最新位置；高峰时网络流量下降约 60%，地图操作不再明显迟滞
• 告警设计：和调度员走访后发现红色告警覆盖底图，看不清附近道路。重新定义严重等级、聚合阈值和选中态，增加键盘定位与文字说明；试点中心查找异常车辆的平均用时缩短约四成
• 稳定运行：定位大屏运行一天后内存增长的问题，发现移除图层时纹理和监听器未释放；建立图层生命周期约定与 72 小时压力测试，上线后大屏不再需要每日人工重启

参与工厂设备监控产品，设备数据由边缘网关每 5 秒上报一次，客户会在车间触控屏和办公室电脑查看。

• 开发设备状态总览和趋势图，按设备类型建立可复用的量纲、阈值和时间轴组件，避免不同页面把摄氏度与华氏度混用
• 对跨度一年的传感器曲线做分层采样：缩小时保留每桶最值，放大后请求原始数据；数十万点数据仍能快速查看突变点
• 参与现场验收，修复高 DPI 工控屏上点击区域太小和断网后状态被错误显示为“正常”的问题，补上最后更新时间与离线状态

项目经历

React / TypeScript / Mapbox GL / deck.gl / Web Worker

调度员要同时看实时车辆、历史轨迹、拥堵热区和报警事件，地图会在一块 4K 大屏和普通办公电脑上使用。

• 给图层定义统一输入协议与优先级：底图、热力、轨迹、车辆、告警各自管理数据源；切换业务场景只启用所需图层，降低 GPU 内存占用
• 轨迹数据先按时间窗口和可视区域裁剪，再按像素误差做抽稀；一条数万点的轨迹通常只需绘制几百个点，视觉上仍保留拐弯细节
• 鼠标拾取使用离屏颜色编码而非遍历所有点位，点选延迟保持在 100ms 以内；对低性能终端自动减少装饰图层
• 建立基于录制数据的回放工具，线上问题可用同一段车辆流复现。半年内用于定位 7 次乱序或坐标异常，减少依赖现场视频猜测

Three.js / TypeScript / glTF / ECharts

客户希望把设备告警定位到厂房楼层和机台，但三维场景必须能在普通办公电脑运行，不能依赖独立显卡。

• 与建模同事约定模型面数、材质数量和纹理尺寸预算；加载前压缩 glTF 并按楼层拆包，首屏只加载当前厂房
• 设备状态通过实例化标记展示，点击机台才加载详细曲线；在集成显卡电脑上首次可交互时间由约 12 秒降到 4 秒
• 为色觉障碍用户提供形状与文字双重告警提示，二维列表与三维视图共用同一份选中状态；项目通过客户现场验收

ECharts / TypeScript / Web Worker / JSON 配置

运营每周要新增十几个指标图表，原来每个都要前端排期开发。

• 把图表抽象为「数据源 + 指标 + 维度 + 图表类型」的 JSON 配置，运营在界面上配置，渲染端生成 ECharts option
• 同比、环比、占比等派生计算在 Worker 里完成，主线程只渲染；一个看板 20 个图表时切换筛选不再卡顿
• 指标定义统一维护口径说明，图表悬停可查看计算方式，「两个看板数字对不上」类的问题明显减少
• 上线后常规看板需求不再进前端排期，团队每月节省约 40 人时

教育经历

个人优势

• 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

工作经历

交易前端组负责商家工作台和用户下单链路，前端 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 Profiler / Chrome DevTools / TypeScript

团队内部工具，记录业务页面一次交互中的组件提交次数和耗时，帮助新人定位“点一下刷新半屏”的问题。

• 用 Profiler 收集 commit 时长与组件树，按交互名称聚合；和浏览器 Performance 长任务对照，避免只凭 render 次数判断性能
• 给常见问题写可复现示例：不稳定的对象 props、过宽的 Context、昂贵的派生计算。半年内用于 9 次性能专项评审，相关页面的中位交互耗时降低约三成

Next.js App Router / React Server Components / MDX

帮助中心原来是客户端渲染的 SPA，商家在搜索引擎里搜不到答案，只能找客服。

• 文档内容改为 MDX + 服务端组件渲染，目录、相关文章在服务端生成，客户端只保留搜索和反馈两个交互组件，页面 JS 体积减少约 六成
• 文章按更新频率分别使用静态生成和按需再验证，运营改完文档几分钟内上线，不用整站构建
• 上线半年，帮助中心来自搜索的访问量增长到原来的 3 倍左右，「怎么设置营业时间」这类基础咨询明显减少

教育经历