个人优势

• 两段前端实习（电商商家中台、在线教育），能独立完成列表、表单和移动端 H5，改动会配单测和性能数据验证
• JavaScript 基础扎实，能讲清事件循环、原型链、闭包和 this 绑定，手写过 Promise、防抖节流、深拷贝等常见实现
• 读过 React 调度器（Scheduler）和 Vue 3 响应式部分的源码，写过一篇 Fiber 可中断渲染的分析文章，掘金阅读 1.4 万
• 维护开源虚拟滚动表格 react-virtual-table，GitHub 1.2k Star，处理过 40 多个 issue，熟悉 npm 包的构建、发布和语义化版本
• 做过性能优化的完整闭环：先用 Performance 面板和 Lighthouse 定位，再改，再用数据对比，实习中把订单列表首屏图片请求从 80 多个降到 30 个左右
• 熟悉移动端兼容问题，整理过 14 条 iOS / 安卓 WebView 的常见坑和解决方案，被实习团队收进新人文档
• 会写简单的 Node.js 服务，用 Koa + MySQL 给课程项目写过接口，能和后端顺畅对接口
• 习惯写测试和文档：实习期间给 20 多个工具函数补了 Vitest 单测，顺带发现了一个日期时区的线上问题
• 英语 CET-6，能直接阅读 React、Vite 的英文文档和 GitHub issue
• 技术栈：JavaScript、TypeScript、React 18、Vue 3、Zustand、Vite、Webpack、Vitest、Node.js（Koa）、MySQL

实习经历

所在团队负责商家后台（订单、商品、售后），日活商家约 8 万，技术栈 React 18 + TypeScript + Ant Design。

• 参与订单中心重构。原来订单列表、退款列表、发货列表 3 个页面各写了一套筛选表单，逻辑有出入，经常改一处漏两处；我把筛选项抽成配置（字段、组件类型、默认值、联动规则），封装 SearchForm 组件统一渲染，后续新增筛选项只改配置
• 订单列表一页 200 行，每行最多 6 张商品图，首屏图片请求 80 多个，弱网下列表要转好几秒。改为 IntersectionObserver 懒加载，并给图片 URL 拼上 OSS 缩放参数按显示尺寸取图，首屏图片请求降到 30 个左右，图片总流量减少约 70%
• 给金额计算、日期格式化等 20 多个工具函数补了 Vitest 单测，过程中发现一个按 UTC 解析日期导致「下单时间少一天」的线上问题，修复后补了时区相关的用例
• 参与每周的 Code Review，整理了一份团队 React Hooks 常见问题清单（闭包拿到旧值、effect 依赖遗漏、列表 key 用 index 等），被组里拿来做新人文档

• 用 Vue 3 + Vite 开发课程报名 H5，负责报名表单、微信支付回跳和分享海报。海报用 html2canvas 生成，处理了跨域图片导致画布被污染、iOS 上生成的图片模糊（按 devicePixelRatio 放大绘制）两个问题
• 处理 iOS 软键盘弹起遮挡输入框、安卓 WebView 下 100vh 包含地址栏导致底部按钮被挡等兼容问题，整理成团队的移动端兼容问题文档，共 14 条，每条附复现机型和解决方案
• 报名页转化埋点原来只有 PV，补上表单每一步的停留和放弃事件后发现「选择上课时间」一步流失最多，配合产品把时间选择改成默认推荐最近一期，报名转化提升约 8%

项目经历

React / TypeScript / Rollup / Vitest

面向后台场景的高性能表格组件，支持 10 万行数据流畅滚动，npm 周下载量 3000 左右，GitHub 1.2k Star，被两家公司的内部项目使用。

• 动态行高：行高不固定时无法直接算出可视区起点。先用预估高度渲染，再用 ResizeObserver 回填真实高度，维护行高前缀和数组，滚动时二分查找起始行，查找复杂度 O(log n)
• 滚动不白屏：在可视区上下各多渲染一屏作为缓冲，快速拖动滚动条时用 requestAnimationFrame 合并滚动事件，避免一帧内多次重排
• 固定列：左右固定列用 position: sticky 实现，不再拆成三张表同步滚动，代码量和滚动抖动都少了很多
• 工程化：Rollup 同时输出 ESM 和 CJS，配置 exports 字段和类型声明，支持 Tree Shaking；GitHub Actions 跑单测和体积检查，PR 体积增长超过 5% 会提示

React / Canvas / WebSocket / Yjs

三人小组的课程设计，支持多人同时画图、移动和删除图形，我负责画布渲染和协同同步部分，课程评分 优秀。

• 用 Yjs 管理白板数据，多人同时修改同一个图形时由 CRDT 自动合并，不需要自己写冲突处理
• Canvas 分三层绘制（背景网格、图形、选中框），拖动图形时只重绘选中层和图形层，200 个图形下拖动保持 60fps
• 断线重连后用 Yjs 的状态向量只同步缺失的更新，不重新拉全量数据；在弱网模拟下断开 30 秒再恢复，画布内容能正确合并

微信小程序 / 云开发 / TypeScript

和两位同学一起做的校内二手交易小程序，上线一学期注册用户 2600 多人，成交 900 多单。我负责前端和商品搜索。

• 商品列表图片多，低端机上滑动掉帧。用分页加载 + 图片按可视区懒加载，长列表超过 200 条时回收顶部节点，滑动基本不卡
• 发布商品时图片先在本地压缩到 1080 宽再上传，单张从 3~5MB 降到 300KB 左右，上传失败率明显下降
• 搜索在云函数里做分词和同义词扩展（如「自行车」「单车」），无结果率从约三成降到一成左右

教育经历

• GPA 3.7 / 4.0，专业排名前 15%，两次获校级二等奖学金
• 主修课程：数据结构、操作系统、计算机网络、数据库原理、编译原理
• 浙江省大学生服务外包创新应用大赛二等奖（团队前端负责人）

个人优势

• 8 年前端经验，近 4 年专注多团队共用的构建、组件和质量基础设施，服务 20 多个业务团队
• 平台建设先找业务阻力再定能力边界，用接入率、构建耗时和故障率衡量成果，而不是功能数量
• 做过从零到一的设计系统：语义 Token、亮暗与高对比主题、组件状态测试，接入后页面交付周期缩短约 25%
• 主导过多仓库到 pnpm Workspace 的迁移，先统一 lint、测试和发布元信息，再抽公共组件，不在一次迁移里同时换框架
• 熟悉构建性能治理：远程缓存、按变更范围构建、产物分析，大型仓库 CI 时间有过成倍下降
• 建立按业务级别配置的质量门禁，交易页要求关键路径冒烟，内部页面不强制同样的性能阈值
• 发布与回滚：Source Map 绑定版本、发布后自动对比错误人数和 LCP，资源缺失导致的回滚从每季度 6 次降到 1 次
• 写过 codemod 和 ESLint 规则推动大版本升级，提供兼容窗口，业务可以按风险分批迁移
• 带 5 人基础建设小组，负责规划、评审和对外支持，平台问题有值班和响应时效
• 保持对一线业务的感知，每季度轮岗参与一个业务需求，验证平台在真实场景里的体验
• 技术栈：TypeScript、Vite、Webpack、Rollup、pnpm Workspace、Turborepo、微前端、设计系统、CI/CD

工作经历

负责云控制台公共前端平台，控制台包含 30 多个产品域、约 70 名前端开发；我带 5 人小组维护构建、组件和监控体系。

• 构建平台：旧仓库一次全量构建平均 28 分钟，业务改一处文案也要等完整流水线。先按包依赖图拆任务，接入远程缓存与受影响包检测；缓存命中时 CI 中位耗时降到 8 分钟，未命中时仍能完整构建验证
• 组件治理：设计系统此前有 3 套 Button 和 4 套表格，升级成本高。和设计、无障碍、业务代表制定 Token 与组件 API，写 codemod 迁移常见调用；一年内核心组件在 21 个产品域接入，重复问题和视觉偏差显著减少
• 发布隔离：控制台多个产品共用一套入口，某产品静态资源错误会拖累整站。建立按产品发布的清单和资源版本锁，保留回滚入口；一次产品配置故障仅影响对应路由，未扩散到其他业务
• 监控标准：规定错误事件必须带产品域、版本、租户与 traceId，统一采集白屏和关键页面性能。告警按受影响用户数分级，线上问题由业务反馈后发现占比从六成降到两成以内
• 团队推广：用 RFC 说明迁移成本和例外情况，每两周与业务组复盘。没有要求一次性重写旧页面，先在新需求中采用，再按业务窗口迁存量；平台月活开发者超过 60 人

负责门店运营系统前端架构，团队从 6 人扩到 24 人，页面和仓库数量迅速增长。

• 将 11 个独立仓库迁入 pnpm Workspace，先统一 lint、测试和发布元信息，再抽公共业务组件；避免迁移初期同时改运行时框架和构建系统
• 给门店订单、库存等高频页面设置体积与 LCP 预算，超出后由负责人解释业务收益或给出拆包方案；典型低端设备 LCP 从 4 秒多降到约 2.5 秒
• 设计前端灰度开关，按门店与用户组放量，回滚只改配置；大促期间两次线上问题都在十分钟内回到稳定版本

项目经历

React / TypeScript / CSS Tokens / Storybook / Playwright

各产品线设计与代码实现长期分叉，用户在不同页面看到不同的表单和导航。目标是建立能被持续维护的共同语言。

• 先盘点 200 多个页面的交互模式，把表格筛选、权限提示和异步状态列为首批，不靠“换颜色”伪装成设计系统
• Token 区分语义与具体色值，亮暗主题和高对比模式使用同一套组件 API；表单字段按错误、警告、只读、加载等状态写测试
• 组件发布采用语义版本和变更说明，对破坏性更新提供 codemod；接入团队可以先替换低风险组件，业务高峰后再迁复杂表单
• 接入一年后，常见后台页面从设计验收到首次交付的平均周期缩短约 25%，组件缺陷由平台组集中修复

Node.js / GitLab CI / Lighthouse / Sentry

平台对每个前端项目提供同一套发布前证据：类型、单测、关键路径冒烟、包体积与性能趋势。

• 质量门禁按业务级别配置，交易页需要关键路径冒烟，内部低流量页不强制相同的性能阈值，避免一刀切拖慢团队
• 把 Source Map 上传与版本号绑定，Sentry 报错能对应到准确源码；发布后自动对比前后版本的错误人数和 LCP 分布
• 平台上线后，因静态资源缺失导致的回滚从季度 6 次降到 1 次；CI 耗时虽然增加约 2 分钟，但故障排查时间明显下降

pnpm Workspace / Turborepo / Rspack / Renovate

主仓库 60 多个包，全量构建 25 分钟，依赖版本各自为政，同一个日期库在产物里出现 4 个版本。

• 引入任务图和远程缓存，只构建受影响的包；构建工具从 Webpack 迁到 Rspack，保留插件兼容层逐步替换
• 用 Renovate 按分组自动提依赖升级 PR，配合构建产物分析标出重复依赖，半年内重复依赖减少约 七成
• 主仓库 CI 平均时间从 25 分钟降到 8 分钟左右，业务团队等待合并的时间明显缩短

教育经历

个人优势

• 三年跨端前端经验，负责本地生活平台的微信、支付宝、抖音三端小程序，合计日活约 50 万
• 推动三端代码用 Taro 统一，从新页面开始渐进迁移，现在大部分需求只开发一次
• 小程序性能有实战：重新划分分包、预下载、setData 只传变化字段，主包从接近 2MB 降到 1.1MB，冷启动减少约四成
• 熟悉三端在登录、支付、分享、定位上的差异，封装了统一适配层，业务代码不再写平台判断
• 参与 React Native 下单链路开发，处理过长列表、图片解码和低端安卓机卡顿
• 弱网和异常流程考虑得比较细：支付回跳状态不一致、重复点击、超时，分别有幂等和提示策略
• 沉淀 40 多个跨端组件，每个组件附三端截图对比，组件改动自动做视觉回归
• 熟悉 H5 与原生之间的 JSBridge 通信，处理过 WebView 生命周期、权限状态刷新等兼容问题
• 有真机回归习惯，和测试一起整理了 12 台常见机型的回归清单，不只在开发机上验证
• 在 CI 里加了小程序包体积检查，超预算阻止合并，PR 里能直接看到体积变化
• 技术栈：微信 / 支付宝 / 抖音小程序、Taro、uni-app、React Native、React、TypeScript、JSBridge

工作经历

负责商家券和外卖下单相关的小程序，三端小程序合计日活约 50 万，组内 7 人。

• 三端统一：原来微信、支付宝、抖音三端各维护一套代码，一个需求要做三遍。推动用 Taro 统一，先从新页面开始，再按访问量逐步迁移老页面，大部分需求现在只开发一次
• 包体积和启动：微信小程序主包接近 2MB 上限，新功能加不进去。按页面访问量重新划分分包，把低频页面和大体积依赖（图表、富文本）移出主包，首页依赖的分包做预下载；主包降到 1.1MB，冷启动耗时减少约 四成
• 渲染性能：商品详情页切换规格时明显卡顿，排查发现是一次 setData 传了整个商品对象。改为只传变化的字段并合并高频更新，切换规格基本无卡顿
• 设备兼容：真机测试中发现部分安卓 WebView 回到前台后定位权限状态没有刷新，用户看到旧位置。监听生命周期并重新检查权限，失败时展示手动选择地址入口；和测试一起整理 12 台常见机型的回归清单

• 参与商城 H5 的多语言改造，抽出文案字典并按语言包按需加载，支持 6 种语言
• 处理不同语言下文案长度差异导致的布局错乱问题，整理了多语言布局规范
• 商品详情页的价格在不同币种下格式不统一，改用 Intl.NumberFormat 统一处理货币和千分位

项目经历

Taro / React / TypeScript

• 平台差异适配层：登录、支付、分享、定位四类能力在三个平台的接口和流程都不同，封装统一的适配层，业务代码不再写平台判断
• 体积监控：在 CI 中加入小程序包体积检查，主包或分包超出预算时阻止合并，并在 PR 里展示体积变化明细
• 灰度和回滚：小程序发版审核慢，关键功能加了远程开关，出问题时不用等审核就能关闭
• 弱网下单：用户从商家页跳支付时可能切到后台，回来后本地状态与服务端订单不一致。提交时带幂等订单号，支付回跳后重新查询服务端结果；对超时、重复点击、取消支付分别给出提示。试点地区相关客服咨询从每周 20 多件降到个位数

React Native / TypeScript / FlashList / Reanimated

App 内的门店列表、商品选购和购物车三个页面用 React Native 重写，覆盖下单流程的主要环节。

• 门店列表从 ScrollView 换成 FlashList，配合固定高度的骨架行，低端安卓机上滚动掉帧明显减少
• 商品图按可视区加载并限制解码尺寸，长时间浏览后的内存占用比原来低了约三分之一，闪退率随之下降
• 加购动画用 Reanimated 跑在 UI 线程，JS 线程忙于计算价格时动画也不掉帧

React Native / Taro / Storybook

• 沉淀 40 多个跨端组件（选择器、弹层、表单项、商品卡片等），三端视觉和交互保持一致
• 每个组件附 Storybook 示例和三端截图对比，组件改动自动生成截图对比，减少视觉回归问题
• 对日期选择、图片上传等系统能力差异大的组件只共用协议和数据校验，各端保留原生交互；减少了大量平台分支，适配新系统版本时也能按端定位问题

教育经历