个人优势

• 三年前端开发经验，主要做 B 端 SaaS，负责过看板、报表、权限和审批几个完整模块，能从需求评审跟到上线复盘
• 熟悉 Vue 3 响应式和编译期优化，参与并主导了 600 多个组件从 Vue 2 迁到 Vue 3，迁移期间业务正常发版
• TypeScript 用得比较深，给团队组件库写过泛型表格、泛型表单组件，类型提示能精确到列字段
• 做过大数据量图表的性能优化：把聚合计算挪到 Web Worker，维度切换不再卡顿
• 有表单引擎的实际经验，基于 JSON Schema 做过联动、校验和可视化配置，目前承载公司 60 多个审批表单
• 重视组件沉淀，封装的表格、筛选栏、弹窗表单配了 Storybook 文档，新做一个标准列表页从两三天缩到一天以内
• 能独立写 Node.js 小服务，用 Koa 写过 BFF 接口和文件上传服务，熟悉分片上传和断点续传
• 有线上问题的排查习惯：接入 Sentry 后按接口报错、白屏、JS 异常分类告警，大部分问题当天就能发现
• 做过 uni-app 小程序，熟悉分包、图片压缩和弱网下的离线提交
• 关注可用性细节，组件默认支持键盘操作和错误状态，低配笔记本上也会自测一遍
• 技术栈：Vue 3、Pinia、Element Plus、TypeScript、Sass、Vite、Webpack、Vitest、Storybook、ECharts、uni-app、Sentry

工作经历

公司做企业级数据分析 SaaS，400 多家企业客户在用。我在 5 人前端组，负责看板、报表和权限三个模块。

• Vue 2 迁移 Vue 3：项目 600 多个组件，不能停下业务需求整体重写。先接入 @vue/compat 让项目在 Vue 3 下跑起来，再按模块逐个消除兼容层警告，Vuex 逐步换成 Pinia；两个月迁完，期间正常发版。构建换成 Vite 后本地冷启动从 40 多秒降到 5 秒，热更新基本即时
• 业务组件沉淀：把表格（列配置、分页、批量操作）、筛选栏、弹窗表单等反复写的模式封装成组件，配 Storybook 文档和示例；新做一个标准列表页从两三天缩短到 一天以内
• 错误监控：接入 Sentry，按接口报错、白屏、JS 异常三类配置企业微信告警，并把用户 ID 和租户写进上下文；之前靠客户反馈才知道的问题，现在基本当天就能发现
• 权限改造：原来按钮级权限散落在各个页面的 v-if 里，抽成 v-permission 指令和路由守卫统一处理，权限配置改为后端下发，新增角色不再需要发版

公司给连锁门店提供收银和巡店系统，我在 3 人前端组，负责门店后台和巡店小程序。

• 用 Vue 3 + Element Plus 开发门店后台的商品、库存和报表页面，独立负责了 20 多个页面的交付
• 报表导出原来是前端一次拉全量数据再拼 Excel，数据超过 5 万行浏览器直接卡死。和后端改成异步导出任务 + 下载链接，前端只负责发起和轮询进度
• 用 uni-app 开发巡店小程序（门店检查表、拍照上传、整改跟踪），门店地下室信号差，检查结果先存本地，联网后自动补交

项目经历

Vue 3 / TypeScript / ECharts / Pinia / Web Worker

客户在页面上自由组合图表、筛选维度来搭建自己的分析看板，一个看板通常有 10 到 20 个图表，单个图表的原始数据可能上万行。

• 主线程卡顿：维度切换时前端要对原始数据重新聚合（分组、求和、同比），放在主线程里一次要算 1 秒多，页面会卡住。把聚合计算移到 Web Worker，用 Transferable 传 ArrayBuffer 避免拷贝，主线程只负责渲染，切换维度时页面不再卡顿
• 图表配置化：设计看板的 JSON 配置（数据源、指标、维度、图表类型、样式），运营在界面上配置后保存，渲染端按配置生成 ECharts option；常规的看板需求不再需要前端排期
• 自适应：大屏模式和嵌入第三方页面时容器尺寸会变，统一用 ResizeObserver 监听容器并节流调用 resize，修复了全屏切换后图表尺寸错乱的问题
• 按需加载：20 个图表同时请求会把接口打满，改为视口内的图表先加载，其余进入视口时再请求，首屏接口数从 20 个降到 6 个左右

Vue 3 / JSON Schema / Monaco Editor / AJV

公司内部 OA 的审批表单原来每个都手写页面，引擎上线后用配置生成，目前承载 60 多个审批表单。

• 基于 JSON Schema 扩展表单协议，加入 x-component、x-reactions 字段描述组件类型和联动规则，联动按依赖图计算，避免循环触发
• 提供拖拽配置和源码编辑两种模式，源码模式用 Monaco Editor，接入 Schema 校验和字段名自动补全
• 校验规则前后端共用一份 Schema（前端 AJV、后端同样的 Schema 校验），避免前后端校验不一致
• 表单字段超过 100 个时输入明显卡顿，排查发现每次输入都触发整张表单的联动计算。改成只重算依赖当前字段的节点，输入恢复流畅

uni-app / Vue 3 / IndexedDB 兼容层

覆盖 300 多家门店的店长和督导，每天提交检查表 2000 份左右。

• 离线提交：检查结果和照片先写本地队列，联网后按顺序补交，重复提交用检查单 ID 做幂等；上线后「提交失败」相关的反馈基本消失
• 图片处理：一份检查表最多 30 张照片，拍照后本地压缩并加水印（门店、时间、定位），单张从 4MB 左右降到 300KB，上传耗时缩短到原来的五分之一左右
• 分包：报表和历史记录页移出主包，主包控制在 1.2MB 以内，首次打开时间明显缩短

教育经历

个人优势

• 三年跨端前端经验，负责本地生活平台的微信、支付宝、抖音三端小程序，合计日活约 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 示例和三端截图对比，组件改动自动生成截图对比，减少视觉回归问题
• 对日期选择、图片上传等系统能力差异大的组件只共用协议和数据校验，各端保留原生交互；减少了大量平台分支，适配新系统版本时也能按端定位问题

教育经历

个人优势

• 4 年 Flutter 开发经验，负责过一款在线教育 App 的 iOS、Android 和鸿蒙三端，一套代码维护三个平台
• 混合栈开发经验丰富：Flutter 页面嵌在原生 App 里，处理过多引擎内存、页面栈同步和原生通信的问题
• 渲染性能有实战：用 DevTools 定位重建范围过大、图片解码和 Shader 编译卡顿，课堂页稳定 60 帧
• 状态管理用 Riverpod，按功能模块划分 Provider，业务逻辑可以脱离 UI 单测
• 做过直播课堂的白板和音视频互动，Platform View 嵌入原生播放器，处理了层级和手势冲突
• 关注包体积和启动速度，Flutter 产物拆分、按需加载字体和图片，安装包减少 18MB
• 技术栈：Dart、Flutter、Riverpod、Dio、Isar、Platform Channel、Kotlin、Swift、ArkTS（鸿蒙适配）、Firebase Crashlytics

工作经历

学生端 App 日活约 60 万，移动端 6 人，Flutter 负责全部学习类页面。

• 直播课堂：课堂页包含视频、白板、聊天和答题四个区域。视频用 Platform View 嵌入原生播放器，白板用 CustomPainter 绘制并按笔迹增量重绘，低端机上课堂页从 40 帧左右提升到稳定 58 帧以上
• 鸿蒙适配：参与 Flutter 鸿蒙版的适配，梳理 30 多个插件的兼容情况，自研插件用 ArkTS 重写平台端；鸿蒙版按期上架，核心功能与 iOS、Android 一致
• 离线学习：课程视频和课件支持离线下载，断点续传、存储空间不足提醒、过期自动清理；离线播放相关的投诉下降约 80%
• 包体积与启动：拆分 Flutter 产物，非首屏资源延迟加载，字体按需子集化；安装包减少 18MB，冷启动缩短约 0.4 秒

负责企业审批 App，团队 5 人，从原生迁到 Flutter 的过程中加入。

• 参与 30 多个页面从原生迁到 Flutter，迁移期间新老页面共存，统一了页面路由和登录态
• 封装审批表单的动态渲染组件，服务端下发配置即可生成表单，新审批类型无需发版
• 用 Isolate 处理大附件的压缩和上传，上传过程中界面不再卡顿

项目经历

Flutter / Kotlin / Swift / Platform Channel

• 原生和 Flutter 页面统一用 URL 路由，页面栈由原生侧管理，返回手势和转场动画两端一致
• 多个 Flutter 页面共享一个引擎，打开新的 Flutter 页面内存增量从 30MB 降到 5MB 左右
• 页面间传参和结果回传有类型约束，减少了因参数拼错导致的线上问题

Flutter / CustomPainter / WebSocket

• 老师端的笔迹通过 WebSocket 实时下发，学生端按笔画增量绘制，不重绘整个画布
• 笔迹数据做了平滑和压缩，传输量下降约 60%
• 支持课后回放：按时间轴重放笔迹，和课堂录像同步

教育经历