← 返回资料库
面试准备 / PERSONAL ARCHIVE

简历项目讲述与追问

围绕 BBDbuy、多端架构、后台、仓库 PDA、TMS 和浏览器扩展整理可直接练习的项目回答。

更新于 2026.09.11指南#BBDbuy#项目经验#React#React Native#架构

内容来源包括本人在简历优化对话中的陈述、当时提供的简历文本，以及 2026-09-02 阅读的本地 BBDbuy 代码。代码能证明项目当前存在这些实现，但个人职责仍以本人陈述为准。没有可靠测量的数据不写成提升百分比。

BBDbuy 跨境电商多端项目

30 秒版本

BBDbuy 是面向海外用户的跨境代购和国际集运平台，包含 PC、移动 H5 和 React Native 三端，覆盖商品、购物车、订单结算、支付、仓库合箱、国际运单、退款、钱包、推广和客服。作为公司首名前端，我主要负责多端架构、公共业务 Flow、核心交易链路、RN 稳定性以及从 CI/CD 到应用商店发布的完整交付。

业务主链路

商品搜索或链接解析
  → 商品详情与 SKU 选择
  → 加入购物车或立即购买
  → 订单预览、优惠与地址
  → 支付
  → 国内采购与入库
  → 仓库验货、合箱
  → 国际运单
  → 收货、售后与客服

项目难点不是页面数量，而是三端需要保持相同业务规则，同时还要处理海外用户、多语言、多币种、第三方支付、原生运行时和发布渠道差异。

简历核心工作推荐组合

篇幅允许时优先保留以下 6～7 条。投 React 岗位优先架构、请求、SKU、支付；投 RN 岗位优先架构、请求、稳定性、深链和发布。

  • 主导将 PC、H5、React Native 三个独立工程整合至 pnpm Workspace + Turborepo Monorepo，按 API、Query、Flow、Types 分层沉淀公共业务包，并通过 Runtime/Adapter 隔离路由、存储、反馈及原生能力差异，实现核心业务三端复用。
  • 建设三端公共请求基础设施，抽离平台无关 Request Client 与 Axios Transport，统一响应协议校验、错误分类、语义化超时和安全遥测；治理并发 401 会话失效，并结合 TanStack Query 实现请求取消及可恢复读取的有限重试。
  • 设计商品详情页 SKU 规格联动与库存可选性算法，基于有库存 SKU 枚举属性组合并构建 Path Map，动态禁用无库存或无效规格，同时统一起购量、库存上限、加购和立即购买流程。
  • 沉淀订单结算与支付公共 Flow，通过唯一预览标识隔离购物车结算和立即购买流程，统一优惠策略、账单地址校验、第三方支付跳转、结果轮询与终态缓存刷新，避免重复提交和旧状态污染。
  • 抽取三端客服聊天公共 Flow，基于 WebSocket 实现连接管理、断线重连、会话隔离、本地回显、回包去重、ACK 超时与失败重发，并支持历史消息分页、未读刷新和图片消息。
  • 负责 React Native 稳定性和 Android/iOS 兼容治理，处理 Expo/RN/NativeWind 大版本升级、iOS Hermes 启动崩溃和 Android ViewPager2/RecyclerView 线上崩溃，并重构高风险标签页交互。
  • 独立建设云效 CI/CD 与 EAS 发布体系，负责 Android/iOS 构建、OTA 兼容边界以及 Google Play、App Store 上架，处理证书、隐私合规和审核驳回问题。

如果简历篇幅紧张，App Links / Universal Links 可以放入面试展开，不必单独占一条。

多端 Monorepo 与业务分层

面试官问：这个项目是什么架构

推荐回答：

它是模块化 Monorepo 下的分层前端架构，并借鉴 Ports and Adapters 思想。PC、H5 和 RN 放在 pnpm Workspace + Turborepo 中；公共业务按 API、Query、Flow、Types 划分，Flow 只依赖 Runtime 或 Domain Port，各端 Adapter 再注入路由、反馈、存储、支付和原生能力。

不要直接说“完整六边形架构”。项目依然使用 React 和 TanStack Query，更准确的说法是：模块化 Monorepo + 业务分层 + Ports and Adapters 思想。

为什么不是简单复制三套代码

复制的直接问题是同一业务规则逐渐分叉。例如购物车选择、订单预览身份、地址校验和支付结果处理，如果分散在三个页面中：

  1. 一个 Bug 需要修改三次。
  2. 三端 payload、状态和校验容易不一致。
  3. 新成员很难判断哪份实现才是业务准则。
  4. 跨端测试和发布难以统一。

Monorepo 解决依赖与任务组织，业务分层解决规则复用，两者缺一不可。

为什么不能把所有东西都放公共包

适合公共化的内容：

  • 三端规则一致。
  • 输入输出合同稳定。
  • 不依赖 DOM、原生模块或特定路由。
  • 能通过 Runtime / Port 注入平台能力。
  • 抽取后确实减少多份状态机。

不适合公共化的内容：

  • 只属于一个端的短期页面样式。
  • 生命周期强依赖某个平台。
  • 强依赖 DOM、原生能力或大型 UI 组件。
  • 只有一次使用、未来复用不明确。

最新公共请求层改造

这次不是普通 Axios 封装

2026-09-02 的本地代码显示，项目新增了独立的 @bbdbuy/request 公共包，并让 PC、H5、RN 三端通过各自 Adapter 注入环境差异。公共业务包只消费平台无关请求合同，不再依赖 Axios。

当前代码可核对到的范围：

  • 15 个业务域使用公共 Request Client。
  • 120+ 个请求动作声明稳定的 operation。
  • Request 包和 Query 策略共有 36 项相关测试。
  • 50 处 Query 将 AbortSignal 传入请求链。

这些数字描述 2026-09-02 的代码快照，不应继续外推为线上性能提升。

解决了哪些旧问题

旧实现由三个 App 分别维护 Axios 拦截器，存在以下风险：

  • Request 层直接弹 Toast 或 Alert，传输、业务与 UI 反馈耦合。
  • 401 可能返回 null 或由不同页面处理，多个并发失败容易重复清理、重复跳转。
  • 错误日志可能保留完整 URL、参数、Body、Header 或响应内容。
  • data ?? msg 会把合法的 false、0、空字符串或 null 当成缺失值。
  • RN 自己维护一套 AbortController 集合，和 TanStack Query 的取消生命周期重叠。
  • 所有接口共享固定超时，读取、登录、写入和上传没有明确语义。

新的分层

Page
  → Flow
  → TanStack Query
  → Domain API
  → BusinessRequestClient
  → Axios Transport
  → Backend

Request：传输、响应解包、错误分类
Query：缓存、读取重试、取消和失效
Flow：业务编排与最终反馈
App Boundary：Toast、账号清理与路由

关键设计

  1. 平台无关请求合同：业务层只看到 get/post/put/delete 和请求选项，不知道底层使用 Axios。
  2. 显式请求语义：使用 authMode、timeoutPolicy、responseMode 和 operation 描述鉴权、超时、响应协议与监控动作。
  3. 统一错误模型：将错误分为 business、unauthorized、network、timeout、cancelled、http、protocol 和 unknown。
  4. 正确解析响应：以 success 判定结果，保留 false、0、空字符串和 null；命令接口允许返回 undefined。
  5. 401 会话协调：只让 required 请求触发账号失效；同一登录会话中的并发 401 合并为一次事件，再由根边界按顺序取消旧 Query、清 Store 和跳转登录。
  6. 有限重试：只有网络、超时、408 或 5xx 等可恢复读取最多补发一次；业务错误、401、普通 4xx、协议错误、取消和 Mutation 不自动重试。
  7. 生命周期取消：Query 使用自己的 AbortSignal；RN 切后台取消活跃读取，但不批量取消可能已经到达后端的下单或支付 Mutation。
  8. 安全遥测：只允许 operation、method、状态码、业务码和 requestId；不记录完整 URL、参数、Body、Cookie、Authorization 或响应正文。

30 秒回答

我把三端各自维护的 Axios 请求逻辑抽成了公共请求基础设施。业务层只依赖平台无关 Client，Transport 统一负责响应解包和八类错误标准化；App 根边界处理 Toast、账号清理和路由。并发 required 401 每个登录会话只处理一次，读取重试和取消交给 TanStack Query，同时日志只保留白名单字段。这次改造的重点是明确错误、重试和会话的所有权，而不是多封装一层函数。

可以引出的追问

  • Axios 拦截器与 Adapter 模式。
  • AbortController 和 TanStack Query 生命周期。
  • GET、POST、幂等与自动重试边界。
  • 为什么 429 当前不固定 500ms 重试。
  • 并发 401 的去重、订阅和闭包。
  • null、undefined、空字符串与空值合并运算符。
  • 错误序列化、隐私数据和可观测性边界。

SKU 规格联动与库存可选性

业务问题

不同采购平台返回的规格结构并不完全统一。用户选择“黑色/M”时，不能只在全部选择结束后才提示无库存；每选一个属性，都要立即判断其他候选值是否还能组成有效 SKU。

方案

  1. 遍历有库存 SKU。
  2. 为每个 SKU 的规格组合生成所有非空子集。
  3. 对子集排序、规范化并生成 Path Key。
  4. 将 Key 写入 Path Map，可附带 SKU ID、库存和价格。
  5. 用户选择某个规格后，把它与其他候选值组合查询字典，不存在则禁用。
  6. 全部选完后精确匹配最终 SKU，并再次校验库存和购买数量。

若有 S 个 SKU、每个有 K 个规格，枚举子集约为 O(S × 2^K × K)；如果每次生成 Key 都排序，更严谨是 O(S × 2^K × K log K)。电商 SKU 的 K 通常较小，指数项受业务约束。

追问钩子

Map/Set、位掩码、组合枚举、Key 规范化、哈希冲突、React 引用语义、useMemo、时间换空间。

订单结算与支付 Flow

为什么难

  • 购物车结算与立即购买有两个入口。
  • 预览数据包含商品、增值服务、地址和账单地址。
  • 优惠券、限时折扣可能有叠加或互斥规则。
  • 钱包、银行卡和第三方支付具有不同返回路径。
  • H5、App WebView 和外部浏览器跳转行为不同。
  • 支付结果需要轮询、终态判断和缓存刷新。

核心设计

  • 用 orderType + previewKey 生成唯一预览身份，隔离两种入口和多次结算。
  • URL 负责定位，Zustand 保存尚未提交的流程上下文，TanStack Query 保存服务端预览数据。
  • 进入支付前使用提交锁；后端仍以业务幂等键兜底。
  • 轮询使用递归 setTimeout，上一轮结束后再安排下一轮，避免 setInterval 请求重叠。
  • 卸载时清定时器和活动标记；终态后停止轮询并刷新订单、钱包等相关缓存。

追问钩子

状态边界、事件循环、闭包、useRef、重复提交、幂等、支付安全、URL 与开放重定向。

WebSocket 客服聊天公共 Flow

聊天不是一个连接 Hook，而是一套业务状态机：

  • 连接中、已连接、断开与重连。
  • 不同订单或运单的业务会话隔离。
  • 本地临时消息、发送中、成功和失败状态。
  • 服务端 ACK 匹配、超时、失败重发和去重。
  • 历史消息分页与实时消息合并。
  • 未读状态和图片消息。

发送时先生成 tempId 并本地回显；服务端 ACK 后使用稳定 clientKey 保持 React 节点身份，同时记录服务端 ID 用于去重和分页。网络断线不假设服务端一定未处理，因此恢复后需要 ACK 查询、幂等键或人工重发策略。

追问钩子

WebSocket 与 SSE/轮询、TCP 有序与业务 exactly-once、指数退避、长生命周期闭包、React key、竞态条件和 EventEmitter。

React Native 稳定性与双端兼容

iOS Hermes 启动崩溃

项目在 Expo SDK 和 React Native 大版本升级后，TestFlight 出现启动阶段崩溃。问题发生在默认环境初始化阶段，最终定位为原生壳使用的 Hermes Runtime 与 Bundle 编译配置不一致。

处理思路：

  1. 区分业务页面异常和原生 Runtime 初始化失败。
  2. 对比崩溃阶段、原生壳、Babel/Hermes 配置和 EAS 构建产物。
  3. 统一 Android/iOS 的 Hermes、编译器和构建配置。
  4. 清理 EAS 缓存，重新构建原生壳。
  5. 将 Runtime、Profile 和构建缓存纳入发布前检查。

这个问题不能依赖 OTA 修复，因为 OTA 只能替换与当前 Runtime 兼容的 JavaScript 和资源，不能替换不兼容的原生运行时。

Android ViewPager2 / RecyclerView 崩溃

线上堆栈指向 ViewPager2 / RecyclerView 的原生回收路径。页面中 Tab 容器较重，存在嵌套横向滚动和多个内容实例并存。

经过方案对比，最终使用单内容实例 + JavaScript 手势切换，只挂载当前内容，从结构上切断高风险原生视图回收路径，并减少重页面多实例成本。回答时需要诚实说明：该方案完成了高风险路径切断和专项验证；没有长期线上数据前，不说“所有崩溃归零”。

分享商品时，需要在已安装 App、未安装 App、未登录和登录回跳之间保留来源与邀请码。

  • Android：Intent Filter、assetlinks.json、正式包名和 Play App Signing SHA-256。
  • iOS：Associated Domains、apple-app-site-association、Team ID 和 Bundle ID。
  • 关联文件应直接返回 200 和正确 Content-Type，避免重定向。
  • 登录回跳只允许内部路由、白名单域名和已知参数，防止开放重定向。
  • 邀请参数在入口集中解析，并覆盖 App 唤起、H5 兜底、登录和注册接口。

CI/CD、EAS 与双商店发布

Web 端基于 Next.js standalone 构建不可变制品，通过版本目录和软链接实现原子切换，再结合 PM2 重载、健康检查和失败回退。这里的“原子”指当前版本指针切换是单个元数据操作，用户不会看到复制到一半的目录。

RN 端需要区分：

  • EAS Build：构建 APK/AAB 或 IPA。
  • EAS Submit：上传 Google Play 或 App Store Connect。
  • EAS Update：在 Runtime 兼容范围内发布 JavaScript、样式和资源。

独立上架的职责可以包括证书、Provisioning、Bundle ID、包名、版本号、商店文案、隐私政策、数据安全、年龄分级、加密出口、测试轨道、TestFlight、Review Notes 和审核驳回处理。不要把公司法务、文案或后台账号相关工作全部说成个人决策。

BBDbuy 运营管理后台

30 秒版本

这是面向采购、仓库、财务、客服和运营团队的一体化管理平台，覆盖 10+ 业务模块和 50+ 页面。我参与从 0 到 1 搭建，重点负责仓储履约、客服聊天、退款财务、数据看板和 CI/CD，业务从收货验货一直贯穿到打包发货和运输。

值得讲的四点

  1. 仓储流程严格依赖真实条码和作业顺序，不是普通 CRUD。
  2. 使用 JsBarcode 本地生成 Code128 条码，支持扫码、打印和补打。
  3. 客服使用全局单例 WebSocket、订阅与生命周期清理；公共 Flow 后续继续补齐 ACK 和失败重发。
  4. ECharts 看板将员工上班与加班作业拆分，用于观察仓库趋势与人员绩效；截图可证明某统计日 12 人完成 4000+ 上架任务，但不能把单日样例说成长期平均。

BBD 仓库小助手 PDA

30 秒版本

这是运行在 Android PDA 上的 uni-app 应用，以包裹、商品和货位条码为入口，覆盖入库、验货、上架、拣货、打包、发货、退货、移位和异常处理。我负责项目搭建和核心功能，重点做了扫码/提交公共能力、影像上传、弱网错误治理与 WGT 热更新。

面试重点

  • useScanner 统一扫码枪与手动输入、条码标准化、自动聚焦、防重复扫描和语音反馈。
  • useSubmit 负责异步互斥、统一结果反馈和异常后释放锁；后端仍需幂等或状态机校验。
  • 图片/视频上传使用并发任务队列、压缩、进度、超时中断、重试、预览和删除。
  • 弱网请求区分 network、timeout、HTTP、business 和 auth；日志应脱敏并限制数量。
  • WGT 只更新前端资源和逻辑；原生插件、权限、Manifest、SDK 变化仍需重新构建安装包。

新智慧 TMS

这段经历要突出成长和实际参与，不要写成独立主导整个系统。

推荐讲法

新智慧 TMS 是面向跨境物流企业的 SaaS 系统，包含单据、财务、仓库、统计和系统配置等模块。我主要参与 React/Umi 业务页面、配置化表格、Handsontable 批量录入，以及仓库 PDA 的 H5 页面与 uni-app 容器联调，也接触了打印机、流水线、PDF 和国际化。

可以讲：

  • createColumns 统一文本、日期、复选框、条码和操作列，减少页面重复配置。
  • Handsontable 提供类 Excel 的复制粘贴、填充、下拉和单元格校验。
  • PDA 是 uni-app 容器 + WebView H5，优点是快速复用，代价是通信、跨域、Cookie、返回栈和离线能力更复杂。

不要说：独立设计整个 TMS、独立负责所有 PDA 硬件、主导公司整体架构迁移。

Manifest V3 浏览器扩展

公司早期使用第三方 SaaS 物流后台，但缺少可用接口，采购人员需要在 BBD 后台与 1688、淘宝、微店等页面逐单查询物流并回填。

浏览器扩展使用：

  • content script 在目标页面读取或写入 DOM。
  • tabs / scripting 定位已登录的采购平台标签页并执行脚本。
  • chrome.storage.local 保存跨页面任务状态和订单映射。
  • 采购平台、采购单号、商品信息和规格组合共同匹配。
  • 只对成功匹配的订单回填，并保留勾选和人工确认。

选择浏览器扩展而不是 Puppeteer，是因为工具运行在运营人员已经登录的真实页面里，能复用现有会话，安装成本也更低。风险包括第三方 DOM 改版、权限范围、隐私数据和自动化结果复核。

这项工作更适合放在 BBDbuy 工作经历中作为业务自动化亮点，不一定单独占一个大型项目。

项目表达的最后检查

  • 是否先讲了业务问题，而不是先报技术栈？
  • 是否明确了个人负责范围？
  • 是否讲了至少一个失败方案或设计取舍？
  • 是否能指出代码、日志、测试或发布记录作为证据？
  • 是否把平台承载规模和个人贡献分开？
  • 是否避免“全部、完全、零崩溃、提升百分之多少”等无证据表述？
自序 · 个人档案 2026-09-11