个人优势

• 两段前端实习（电商商家中台、在线教育），能独立完成列表、表单和移动端 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%，两次获校级二等奖学金
• 主修课程：数据结构、操作系统、计算机网络、数据库原理、编译原理
• 浙江省大学生服务外包创新应用大赛二等奖（团队前端负责人）

个人优势

• 5 年移动端经验，前 2 年做 H5，近 3 年负责电商 App 的 React Native 业务，RN 页面占全 App 的六成以上
• 主导 RN 从旧架构升级到新架构（Fabric + TurboModules），处理了第三方库兼容和原生模块迁移
• 性能问题能定位到具体层面：JS 线程阻塞、桥通信过多、列表重渲染还是原生渲染慢，分别有对应的工具和方案
• 能写 iOS 和 Android 原生模块，做过支付、推送、相机和本地存储的封装
• 搭建过热更新平台：差量包、灰度发布、版本回滚和崩溃自动回滚，发版不再受应用商店审核限制
• 重视一套代码在两端的体验一致：手势、键盘、状态栏和安全区都有统一的封装和测试清单
• 技术栈：React Native、TypeScript、React、Hermes、Reanimated、FlashList、Zustand、Objective-C / Swift、Kotlin、Detox

工作经历

App 日活约 120 万，覆盖东南亚 5 个国家；移动端 9 人，其中 RN 4 人、原生 5 人。

• 新架构升级：RN 从 0.68 升级到 0.74 并开启新架构，逐个梳理 40 多个第三方库和 12 个自研原生模块的兼容性，自研模块改写为 TurboModules。升级后商品详情页首屏渲染时间缩短约 35%
• 长列表性能：商品瀑布流在低端 Android 机上掉帧严重。换用 FlashList，图片按尺寸裁剪和预取，列表项去掉不必要的重渲染；低端机滑动帧率从 38 帧提升到 55 帧以上
• 热更新平台：自建差量热更新，按国家、版本和用户比例灰度；新版本崩溃率超过阈值自动回滚。业务需求从提交到全量的时间从一周缩短到 1 天以内
• 支付与原生能力：封装 5 个国家的本地支付 SDK，统一成同一套 JS 接口，新增支付渠道的接入时间从两周降到 3 天

前期负责 H5 活动页，后期参与 App 的 RN 化改造，团队 7 人。

• 把门店详情、订单列表等 8 个高频页面从 H5 迁到 RN，页面打开耗时从 1.8 秒降到 0.6 秒
• 封装 RN 与 H5 共用的业务请求层和埋点 SDK，两端数据口径一致
• 搭建 RN 页面的 Detox 冒烟测试，覆盖登录、下单和支付主流程

项目经历

Hermes / Flipper / 自研 SDK

• 采集页面首屏时间、JS 线程卡顿、桥调用次数和内存，按页面和机型聚合
• 发现商品页一次渲染有 300 多次桥调用，合并后首屏耗时下降约 20%
• 卡顿超过阈值时自动采集 JS 调用栈上报，定位到多处在渲染期间做大量计算的代码

React Native / TypeScript / Reanimated / Storybook

• 沉淀 60 多个业务组件，动画统一用 Reanimated 在 UI 线程执行
• 每个组件附 iOS 和 Android 两端的截图对比，Storybook 里可以直接切换平台预览
• 安全区、键盘避让、深色模式统一封装，新页面基本不再出现两端表现不一致的问题

教育经历

个人优势

• 5 年全栈经验，近两年在创业团队独立负责一款 AI 写作产品的前后端，从 0 做到付费用户 1.2 万
• 前端能做好流式交互：打字机效果、中断续写、多版本对比，长文档编辑时不卡顿
• 后端能搭完整的模型服务层：多厂商模型统一接入、超时降级、按用户计量计费、用量告警
• 会做提示词工程但不迷信提示词，结构化输出用 JSON Schema 约束，失败自动修复或重试
• 做过文件解析和长文本处理：PDF、Word、网页导入，超长内容分段摘要再合并，保留原文出处
• 有产品意识，自己看漏斗和留存数据，改过三版新手引导，次日留存从 21% 提到 34%
• 能独立负责部署和运维：Docker、CI/CD、日志和告警都是自己搭的，线上问题能一个人从前端查到数据库
• 技术栈：TypeScript、Next.js、React、Node.js、Python、FastAPI、PostgreSQL、Redis、Docker、Vercel AI SDK

工作经历

团队 7 人，我是两名工程师之一，负责编辑器、模型服务和支付计费，另一位同事负责移动端。

• 长文生成：一次生成五千字以上时经常超时或前后矛盾。改成先出大纲、用户确认后分节生成，每节带上大纲和前文摘要；生成失败只重试单节。长文完成率从 58% 提到 93%
• 多模型接入：封装统一的模型调用层，三家厂商同一套接口，按任务类型和成本选模型，主模型超时 15 秒自动切备用。厂商故障期间用户侧报错率控制在 1% 以内
• 计量计费：按实际消耗的 token 计费，预扣、结算、退还三步写在一个事务里，并发请求不会扣成负数；接入支付后上线首月对账零差错
• 编辑器体验：AI 改写以修订模式呈现，可以逐段接受或拒绝；流式输出时编辑器只更新最后一个段落，万字文档里输入延迟保持在 50ms 以内
• 增长实验：自己埋点、看漏斗，发现多数新用户卡在“不知道写什么”，加了按场景的模板入口，新用户首次生成率提升约 17 个百分点

负责商家后台和数据报表，前后端都写，团队 10 人。

• 用 Next.js 重写商家报表页，大表格虚拟滚动，报表导出改为后台任务，十万行导出不再拖垮接口
• 设计报表的预聚合表和定时任务，核心报表查询从 6 秒降到 400ms
• 2023 年用 GPT 接口做了商品描述生成的内部工具，试用商家 300 多家，是后来转做 AI 产品的起点

项目经历

Next.js / Tiptap / Vercel AI SDK / FastAPI / PostgreSQL

• 编辑器基于 Tiptap 扩展了 AI 改写、续写、扩写三种节点操作，结果以修订标记插入，撤销栈与普通编辑共用
• 流式结果按段落缓冲后再写入文档，避免逐字写入导致的光标跳动和协同冲突
• 文档历史版本按段落存差异，用户可以对比任意两次 AI 改写的结果

Python / Unstructured / pgvector / Celery

• 支持 PDF、Word、网页链接导入，解析在 Celery 队列里异步执行，前端按阶段显示进度
• 用户写作时可以引用导入的资料，生成内容里的引用带原文段落，点击可以跳回原文
• 扫描件、加密文件给出明确提示，解析失败率从 9% 降到 2%

教育经历