简历修改上下文

本次改稿按 React / React Native 求职方向，将重复的职责和功能清单压缩为代表案例，优先呈现三端共享工程、公共请求治理、RN 稳定性、结算支付与发布交付；随后根据本人提供的本地对话，补入后台登录依赖与发布制品检查。根据本人对过度压缩的反馈，后台与 PDA 已恢复为两个独立项目。2026-10-09 又依据本人提供的本地 PDA 代码，补入广播扫码、上架单件状态控制、拍照上传恢复及请求诊断，收紧原更新表述。2026-10-13 补入本人确认的团队职责，并根据后续反馈恢复主项目 SKU 与聊天素材、补充平台业务简介，将技术能力展开为六条；同日根据本人提醒及本地代码核对，新增 PDA 的 UTS 原生水印模块。求职简历保留修改后的正文；来源、取舍和待核实信息集中在这里，供本人阅读及下一次对话使用。

初次改稿日期为 2026-10-08，PDA 代码补充日期为 2026-10-09，团队经历及主项目、技术能力调整日期为 2026-10-13；2026-10-17 继续完善简历正文，2026-10-19 根据本人提供的本地 BBDBUY 仓库重新核对并写入主项目建议稿，具体取舍见下文同日记录。本文记录编辑决策，不将改写后的措辞自动视为本人对每项技术职责的新确认；明确确认的团队职责单独记录如下。

本次请求与文件用途

本人要求完成简历精简、排序、必要的增删，并新增一份解释修改依据的上下文，简历正文保持完善后的模样。补充询问第二份工作时，本人明确表示：“那家我不想写在简历里，就三个月。”因此，新简历省略这段任职，真实时间线仍保存在职业资料与本页。

文件	稳定标识	用途
求职简历.md	resume-current	当前精简重排版，作为后续简历修改的起点
简历修改上下文.md	resume-revision-context	修改理由、来源边界、候选素材及核实入口
简历技能与项目对照.md	resume-skills-projects	当前技能与项目案例的对应关系、确认范围及待定位素材
职业经历与BBDbuy.md	career	本人提供的真实职业背景和公共请求层补充
最新简历.md	resume-latest	2026-09 原简历存档，保留原文与后来的时间更正

旧文件名为“最新简历.md”，但它的标题和状态已经是“2026-09 简历存档”。本次保留旧文件和 slug，新增当前版本，避免覆盖历史原文或破坏已有引用。

新简历的元数据状态暂为“待填写”，表示仍有具体职责与教育日期待核实，不代表还要补回三个月的工作，也不代表精简工作未完成。原改稿正文不放修改说明、核实清单或空白占位；2026-10-17 本人明确要求在模块下显示规则，最初采用括号，后续改用 Markdown 引用块与列表。2026-10-21 又按本人要求，在 BBDBUY 已讨论到的项目内部段落和第一条前增加同样结构的编写说明，直接解释内容用途与保留理由；详细来源、历史取舍与待核实清单仍集中在本页。两份新文档均不默认选入 AI 导出；讨论简历时按需一起选择。

当前模块规则与使用方式（2026-10-17）

本人提出先定义每个模块记录什么、不记录什么，并要求直接在模块下呈现，补充模块的目的和记录理由。初次按本人要求写为括号，随后本人指出长括号不够美观，现统一改为 Markdown 引用块，使用加粗标签与四条列表分行呈现“目的、记录、不记录、理由”，规则内容保留。基本信息沿用姓名作为页首入口，引用块标题标明模块名称。

这些模块规则属于本轮逐模块完善所用的编辑说明，不是个人经历或能力声明。后续新增内容先判断所属模块，具体业务与实现细节归入项目，技能栏保留能力范围。允许 React、WebSocket、Monorepo 等必要关键词在不同层级出现，避免同一案例被多处完整复述；不为去重机械删除有价值的经历，也不固定每个模块的条数或强制填写量化结果。

本人明确指出已生疏的技术，可从当前技能中弱化或移出，历史经历仍按事实保留；本人补充具体项目事实，不自动等于熟练度、个人独立主导或所有模块都需增加同一内容。每轮按当次请求调整相关部分，修改依据继续在本页保留。

每轮回答简历内容问题、提出修改建议或实际修改前，先读取当前简历中对应模块的规则及本页的最新约定，检查内容归属、表达粒度和事实依据，再作出判断；修改后复核受影响模块的规则一致性和重复解释。对本人追问先给出保留、概括或移到其他模块的理由，不把每次提问都自动当作删改指令。技能中可以保留具体技术名与通用能力场景，避免把“不展开项目细节”误解成“只列工具名称”。

项目根目录 AGENTS.md 的 Resume editing 节已设为明确的读取入口，指向当前简历和本页。模块规则内容仍保存在简历各模块下，通用约定、修改来源和最新取舍在本页维护；后续在本项目工作时沿该路径读取，不只依赖本次聊天记录。

修改技术能力、项目经历或两者的对应关系时，加读“简历技能与项目对照”。该页保存当前索引与待定位素材，本页继续保存来源和取舍；项目完善时同步相关行，全部项目完成后再双向复核，不把对应关系当作新的个人职责或熟练度确认。

品牌展示统一使用“BBDBUY”。依据为本人于 2026-10-17 确认公司 Logo 全部大写，并要求后续固定大写；当前简历及后续改稿沿用该写法，历史引文、文件名和代码标识按原记录保留。

2026-10-20 编辑标准与复核方式

本人反馈，不知道该按什么标准写简历：AI 经常在写完后又改变评价，先说一种表达好，追问是否合适时又说不行。本轮问题在于 AI 没有持续区分内容要求与表达偏好，把新增素材、详略取舍及范文风格放在不同标准下反复评价。此反馈不自动构成重写或删除正文的指令；本轮保留正文，以 2026-10-19 已提交版本为后续修改基准。

以下作为后续编辑的固定执行约束，与已有模块规则一起使用，不将 AI 建议记录为本人已接受的新文风或新的个人经历：

事实与职责准确。 时间、规模、个人承担及实现范围有来源；本人已明确确认的事实持续有效，不因讨论措辞重新降为待推定内容。没有依据的指标和收益不能添加，但简历不强制每条都量化。
模块各有用途。 概述说明定位，技能说明能力范围，工作经历说明任职与责任，项目说明具体工作与案例。不因技术词重复出现就机械删除，也不把全部细节都挤进技能或概述。
读者能理解工作。 项目整体能说明服务对象、本人范围及代表工作；案例说明做了什么，并在必要时交代问题、处理理由或已确认的变化。不要求每条机械套齐背景、难点、方案、结果，也不凭“更像故事”否定准确清楚的技术条目。
技术内容服务于判断。 必要技术名可以保留，同时说明用途；边界条件是否展开，按其能否帮助理解贡献判断，不在“抽象更专业”和“越通俗越好”之间反复切换。
详略按代表性选择。 当前求职方向为通用前端开发工程师，保留已确认的主要建设范围及差异明确的案例；不固定条数，不为压缩随意删掉 SKU、聊天或其他已有价值的案例。条目式与叙述式均可采用，当前分点结构继续作为默认，不以某份 GitHub 范文取代已有规则。

2026-10-22 本人再次指出，AI 先评价条目合适，等被追问工具、算法或专用名词时又建议补充，即使已经写入规则也未在初次审阅时执行。本人明确要求后续按规则主动判断，不再等待提醒。以下作为上述标准的执行步骤，不以继续增写规则代替实际复核：

核对事实与范围。 明确当前表述的来源和适用条件，不能仅因源码存在就扩大个人职责或已验证成果。
核对主题覆盖。 判断条目是否说明当前主题所需的问题、处理方式和必要约束，不能将“事实没错”直接等同于“审阅已完成”。
主动判断关键方法。 对照已核实的实现，检查是否遗漏能解释该案例处理手段、具有代表性且可简洁表达的方法；也要判断现有业务语言是否已经说明清楚。必要技术名应结合职责保留，不因前文出现过就省略，也不因本人问到术语就一律建议增加。
检查粒度并给明确结论。 沿用下表的分类，主动说明建议改什么、为什么，或为什么保留；可选细化说明收益与篇幅代价，不把所有可能补入的细节都当成建议。上述步骤用于内部验收，对本人简短报告明确推荐和必要理由，不要求逐项展示检查清单。

2026-10-29 本人进一步明确第三、第四、第五条的表达目标：既要保留第三条“位运算与 Path Map”那样能说明具体处理方法的技术内容，也要简短、易读并覆盖主要业务，不能在完整实现清单与纯功能概述之间反复切换。先选择与用途直接对应、最有代表性的方法，再概括周边流程；压缩时优先收起字段、参数和回调步骤，不把关键方法一并删除，也不为技术感追加无实际信息的术语。第四、第五条最新采用版本见“2026-10-29 第三至第五条的技术方法与简述平衡（当前采用）”，同日此前的短稿作为阶段记录。

再次被问“这样合适吗”时，先验收现稿，允许结论为“可以保留，无需修改”，不自动开始寻找新的改写方向。反馈必须区分：

反馈类别	判断依据与处理
必须修正	指出具体原句、违反的事实或模块规则、证据和影响；如确有表达问题，说明读者会误解什么。不能仅以“我更喜欢另一种风格”列为必须修改。
可选优化	说明改动的收益和代价，例如更短但细节更少、更连贯但扫描更慢；同时承认保留现稿也成立，不宣称新写法是唯一正确答案。
建议保留	已准确传达工作、有区分度且无具体问题的内容继续保留，不为体现本轮提供了建议而换词或重排。

已采用的取舍，在没有新事实、具体问题、岗位目标或本人偏好变化时保持稳定；确需调整时说明触发依据及影响范围，不整版推翻。新增素材与投递表达的详略是不同维度，不能昨天为保留事实补齐内容、今天因范文较流畅就宣布旧版不合格。

当前判断：已提交版本具备项目背景、个人责任与具体案例，继续作为可使用、可维护的基准。BBDBUY 部分条目较密，属于可以讨论的表达优化，尚不足以要求重新写一版；上一轮“更像工程说明”的概括应收窄到这一具体问题。此处不宣称教育日期、逐项验证和既有待核实事项已解决，也不新增投递、面试或成果记录。本轮只更新本页编辑约束，没有修改简历正文或技能项目关联。

依据与事实边界

依据	可以支持的内容	使用边界
2026-10-08 本次本人要求	精简重排、新增修改上下文、主动省略三个月任职	授权编辑不等于确认全部旧简历职责
2026-10-07 本人时间线更正	三份工作及中间休息、旅行阶段	月份含约数，不能沿用旧简历日期或用自然跨度计算工龄
本人关于 BBDbuy 的陈述	承担主要建设工作，借助 Codex 开发	“几乎都是我做的”不能替代每个案例的职责核对
2026-09 公共请求层补充	本人明确表示该轮优化由自己完成；已有代码快照记录具体规则	没有可靠的性能、效率提升百分比
2026-10-08 本人提供的本地 Codex 对话及后台提交 794d3fd	登录与业务依赖拆分、动态加载、禁用发布 Source Map 和制品检查已实现	代码与静态制品可以核对；后端鉴权、静态资源访问限制及线上效果不能据此写成已完成
2026-10-08 对后台业务模块的只读核对	包裹分箱与分配校验、条码打印、客服连接管理、退款和作业统计的当前实现	实现存在不等于已经逐项确认个人主导程度或线上效果
2026-10-08 本人指出后台与 PDA 压缩过度，并提醒广播模式	应保留两个项目的具体技术特点；当日将广播模式记为待补	当日没有 PDA 源码依据；该待补入口已在 2026-10-09 根据本地代码更新
2026-10-09 本人提供本地 PDA 仓库并要求补充	广播接入、上架单件流程、影像上传恢复、本机诊断和 WGT 更新的当前实现	只读核对，未运行公司项目或设备测试；代码注释不替代实测、后端核验和个人职责确认
2026-10-13 本人补充团队经历，并对具体职责回答“都有”	包包达前期唯一前端、后来新增两名前端；参与招聘面试与筛选，承担带教、任务分配、方案把关及代码评审	团队扩充的具体时间、正式管理职级和量化成果未确认
2026-10-13 本人指出主项目 SKU、聊天未写入，项目简介和技术能力过于简略	恢复两类旧简历素材、补充业务范围，并按实践领域展开技术能力	本次为内容取舍调整，不等于新核实每项实现、个人主导程度或技能熟练度
2026-10-13 本人补充苹果、安卓图片水印经历、要求查看代码，并进一步确认已实现、测试跑通	UTS 桥接 Kotlin / Swift 的原生水印实现、双端源码及本人确认的功能验证结果	测试通过依据本人最新陈述；代码快照中正式照片业务仍走 Canvas，具体测试设备、版本及上线范围未单独记录
2026-09-11 提供的 PDF 简历存档	技术案例、公司名称、联系方式和原表述的来源	时间已更正；其余逐项职责与指标仍主要沿用旧记录，未在本次独立核实
2026-10-17 本人更正新智慧职责	本人明确未参与传统 MVC 向 React / Umi 的架构迁移	旧简历及此前建议中的迁移参与表述失效，不作为个人工作经历或技能依据
关于我及项目资料	已确认的学校、专业、学历；项目实现范围和技术背景	教育起止月份未单独核实；依赖和文档不等于个人熟练度

初次改稿使用“承担主要建设工作”“参与”“开发”“建设”等表述，删除“5 年经验”“首名前端”“前端方向负责人”“统筹 3 人”和多处“独立”“主导”，以收紧当时尚未核实的表述。2026-10-13 本人补充后，已恢复前期唯一前端、团队由 1 人扩充至 3 人的背景，并写明具体招聘与协作职责；其余职责仍按各自来源判断。

2026-10-13 团队经历与职责补充

本人指出工作经历应体现“原本就我一个人后面招了两个”。进一步询问是否为包包达前端团队，以及是否参与招聘面试与筛选、带新人、分配任务、技术方案把关和代码评审时，本人回答“都有”。本次据此确认上述人数变化与具体职责。

该轮在简历的包包达工作经历中保留多端建设范围，补充“前期作为唯一前端”，并新增一条：“参与前端招聘面试与候选人筛选，团队后续由 1 人扩充至 3 人；负责新人带教、任务分配、技术方案把关与代码评审。”团队角色集中写在工作经历，项目栏继续说明具体技术案例。

岗位名称保留“前端开发工程师”。“前期唯一前端”沿用本次明确陈述，不额外扩大为公司历史上的“首名前端”；参与招聘与实际带教、分工、技术把关也不自动等于正式管理任命。没有新增团队扩充月份、绩效管理职责或效率提升指标。

2026-10-13 主项目与技术能力调整

本人进一步询问主项目为何没有商品 SKU 和聊天功能，并担心项目简介过于简略；随后指出技术能力也被压缩得过短。本次保留原有五个工程与交易案例，恢复 SKU 规格联动、三端客服聊天两条，并把平台简介补充为服务对象、三端与多语言支持，以及选购、结算、支付、仓储物流和配套服务的业务范围。

SKU 条目保留有效属性组合、Path Map、无效或无库存规格禁用及购买数量约束；聊天条目保留公共 Flow、会话隔离、本地回显、去重、ACK 超时和失败重发。这些内容沿用 2026-09 简历素材，体现业务交互与异步状态处理，与工程整合及请求治理各有侧重。三端聊天聚焦消息流程，后台客服通信聚焦组件、订阅和连接生命周期，两处分别保留。未新增性能指标、算法复杂度、消息必达或线上效果保证；具体设计、实现与验证责任仍需分别核对。

技术能力从三条展开为 Web 开发、移动端与设备应用、数据与实时通信、工程架构、质量与交付、AI 协作六条，依据旧简历与现有项目资料，写明技术及对应实践。项目栏继续展开具体案例，技能栏提供能力范围的概览；不恢复“扎实掌握”“熟练使用”等未经单独确认的评级，也不把本次编辑当作新的熟练度确认。

内容取舍按岗位相关性、案例差异和可讲清楚的程度判断，不再将主项目固定为四至五条。简介补足业务背景，具体工作保留处理方式；用户量、订单量和精确语言数量仍按原来源边界处理。

时间线如何处理

阶段	本人提供的时间线	新简历处理
第一份工作	约 2022 年 4 月至 2024 年 3 月	写为 2022.04—2024.03（约），公司名沿用旧记录，月内边界待核对
休息	2024 年 3—6 月，约三个月	保留在背景资料，不列为任职
第二份工作	2024 年 6—9 月，约三个月前端工作	按本人本次明确选择省略，不补造公司名和项目
旅行与继续休息	2024 年 9 月后至 2025 年 4 月前；旅行约一个月，具体月份未提供	保留在背景资料，不补齐旅行日期
当前工作	2025 年 4 月起	写为 2025.04—至今，公司名沿用旧记录

省略第二份任职后，简历工作栏展示两家公司，但真实经历仍是三份工作。第一份工作的结束与休息开始均在 2024 年 3 月左右，月份之间的具体边界尚未核实。省略的任职不会并入前后公司的日期。

项目栏暂不写起止日期。当前公司入职日期不能自动成为所有 BBD 项目的启动日期；项目资料记录 Monorepo 迁移于 2026 年 7 月完成，也不能用完成日期倒推整个项目开始时间。

标题和概述删除“5 年”“5 年以上”。如后续需要展示累计工作年限，应按实际任职时长核算，并计入被主动省略的短期任职，排除休息和旅行阶段。

教育栏保留本人已确认的学校、专业与学历，暂不写旧简历中的入学和毕业月份。删除年龄与重复的基本信息表，保留姓名、求职方向、当前城市、电话和邮箱。

为什么这样排序

整份简历按“职业概述 → 技术能力 → 工作经历 → 项目经历 → 教育经历”排列。概述交代方向，技术能力便于快速识别匹配项，工作经历说明任职范围，项目经历解释具体做法。概述与技能保留少量必要关键词，具体实现只在项目中展开。

项目顺序是 BBD 三端平台、BBD 运营管理后台、BBD 仓库小助手 PDA、新智慧 TMS。这个顺序优先呈现最近且与 React / React Native 定位最相关的经历，再补充业务履约、现场作业与早期开发经验；它是本次编辑判断，不代表新增了职级或能力评级。

2026-10-13 版主项目的七条内容按以下顺序排列；当前顺序以“2026-10-20 BBDBUY 八项重点提炼”节为准：

顺序	内容	排序理由
1	三端工程整合	先交代共享层与平台适配边界，使后续业务与请求治理有背景
2	公共请求治理	本人明确确认过这一轮工作；错误、鉴权、取消和重试规则能展示具体工程选择
3	RN 稳定性	与 React Native 求职方向直接相关，具体崩溃场景比升级清单更有辨识度
4	SKU 规格联动	呈现商品选购中的有效组合、库存约束与复杂交互
5	结算与支付	用交易链路说明业务状态隔离、提交保护和结果同步
6	三端客服聊天	呈现会话与消息状态处理，补充实时通信案例
7	构建与发布	展示代码到上线的交付范围，保留回退与 OTA 兼容等关键机制

初稿曾将后台与 PDA 合并为同一业务组、共三条正文。本人随后指出很多内容被删去，且广播模式没有体现。2026-10-08 恢复为两个独立项目，后台保留四条、PDA 保留三条；2026-10-09 核对 PDA 代码后，PDA 调整为广播扫码接入、上架作业控制、媒体采集上传、拍照留档与恢复、请求诊断与更新五条。精简优先删除重复的职责和流程罗列，保留可追问的技术处理，篇幅不再固定为两个项目合计三条。

增删与合并记录

原内容	本次处理	理由
职业概述中的全流程能力、团队协作、工程规范、CI/CD 长串表述	压成两句话，围绕方向与主要工作	与后文重复，且部分是宽泛能力判断
工作经历中的 Monorepo、Flow、规范、CI/CD	具体实现集中到项目栏	工作栏交代角色与范围，减少重复展开
第三方物流后台浏览器扩展	保留在 BBD 工作经历	“缺少接口时打通业务”的场景明确，补充多端平台之外的业务工具职责
公共请求层与错误治理	新增为主项目第二条	职业资料有本人明确确认和具体规则，旧简历缺少这一轮补充
RN、Expo、NativeWind 的升级版本号	从正文删去，保留故障与重构方式	把篇幅用于问题、做法和边界；升级记录仍可作为面试素材
SKU 规格联动	初稿移出；2026-10-13 恢复为主项目独立条目	有效组合与库存约束能呈现电商业务交互，不应仅为控制条数而删去
三端客服聊天	初稿移出；2026-10-13 恢复为主项目独立条目	保留会话隔离、回显、去重与失败重发，呈现异步消息流程
商品分享与邀请链路	继续保留为候选素材	按具体 RN 或增长岗位的相关性选择，当前主项目已覆盖交易、通信、工程与交付
后台与 PDA 的两份流程清单和“从 0 到 1”	恢复独立项目，业务范围写入描述；后台四条，PDA 于 10 月 9 日补充为五条、10 月 13 日新增原生水印后为六条	纠正合并后过度压缩的问题，保留后台管理与现场作业的不同技术特点
后台常规功能及新补充的工程改造	分别保留分箱条码、客服通信、退款统计与登录发布四条	工程治理不再挤掉已有的业务与通信案例
PDA 上传、弱网与更新被合在一条	将影像上传与弱网更新分开，恢复队列、超时、重试及 WGT 更新链路	分别呈现异步任务处理和设备维护，避免只剩宽泛能力名称
本人新提醒的 PDA 广播模式	2026-10-08 先记为待补；2026-10-09 核对后新增广播接入与上架作业控制	将硬件通道、输入焦点和业务状态分别说明，保留未提交广播留痕及异常处理
PDA 通用媒体与入库照片链路	分为媒体采集上传、拍照留档与恢复两条	限并发和字节进度属于商品媒体组件；水印与登记结果核对属于拍照链路，避免混为统一能力
PDA UTS 原生水印模块	2026-10-13 核对双端源码后新增独立条目，并根据本人后续确认写明已完成功能验证	展示原生图片处理与跨平台桥接，记录已实现、测试跑通及现有业务接入范围
PDA 原“幂等重试、脱敏日志、静默更新”	当时改为网络超时重试、请求编号关联、部分字段遮罩与确认更新流程；2026-10-21 本人另行确认具体幂等重试场景，见同日补充	当时仅有客户端代码与注释，不能证明后端保障；最新本人确认支持该具体场景，不扩大到全部写接口。字段遮罩与更新流程的原边界继续保留
TMS 的完整页面、合同、打印、国际化清单	保留复杂表格与容器设备联调两条	早期经历用两个代表案例支撑，避免与工作经历重复
技能特长与依赖清单	初稿压为三条；2026-10-13 按实践领域展开为六条	纠正工具名过度拥挤、实践范围不清的问题，每条交代技术与对应工作
“扎实掌握”“熟练使用”等评级	改为技术栈和项目实践	实现存在与个人熟练度需要分别判断
AI 协作	保留一句 Codex 辅助开发与验证方式	保留本人真实协作背景；不增加效率百分比或独立完成所有工作的暗示

业务数据为何暂时移出

旧简历列出的平台与仓库数据如下，本次没有把它们写成当前指标：

原记录	来源及当前处理
7 万+客户、10 万+有效订单、1.6 万+有效运单	2026-09-11 提供的简历存档口径；统计时间、定义和个人贡献关系待核实
近期单日订单约 3000～4000 单	同一存档；“近期”所指区间和订单口径待核实
10+业务模块、50+功能页面；TMS 89 个页面	系统覆盖规模，不能直接等同个人完成量
12 名作业人员单日完成 4000+件上架	原文描述仓库作业统计，缺少改动前后对照，不能直接写为个人带来的效率提升

数据的作用是说明业务规模或具体结果。后续核实后，可选一至两个最有解释力的指标补回，附统计时点、单位与范围；没有测量依据的复用率、性能和效率提升不补造。

2026-10-19 本人新补充平台累计用户约 16 万，并确认新系统于 2026 年 5 月正式上线接替旧系统，已按最新陈述补入项目简介。上表保留旧版来源，“7 万+客户”与本轮“累计用户”的统计时点及口径未证明一致，不据此计算新增用户或增长比例；具体使用边界见下文“2026-10-19 平台规模与正式上线背景补充”。

后台登录依赖与发布检查的补充依据

本节保留 2026-10-08 的来源与验证范围；后台当前正文及编写取舍见“2026-11-07 运营后台按业务组件与交互重组（当前采用）”。

本人在本次改稿后提供本地 Codex 对话查看这份文档，希望判断后台安全或分包工作是否值得补入。这里的“分包”指前端代码按需加载，与仓库业务中的包裹分包不同。

对话记录了本人请求拆出登录页不需要的接口与业务依赖，并通过 Codex 实施修改。本人也提醒登录页应保留用户详情请求，以识别已有登录会话。代码与本地提交 794d3fd 可核对到：

登录与公钥接口独立到 auth，用户详情检查独立到 session；登录成功后确认用户信息，再进入后台。
头像组件使用 React.lazy，WebSocket 和客服服务使用动态 import，减少登录阶段对后台业务的同步依赖。
发布构建关闭 Source Map；制品脚本在发现 .map 文件或 sourceMappingURL 引用时返回失败。
当前可读的本地 dist 和 dev 制品中未检索到映射文件或映射引用，存在异步代码块。本次只读核对公司仓库，没有重新执行构建、联测或部署。

对话中还记录过 dev/pro 构建、Source Map 定向检查与注入残留的拦截检查通过，以及本机模拟登录时后台业务包在登录后下载。模拟验证和静态制品能支持加载与构建行为，不能替代真实后端联测或线上验收。对话同时记载全仓类型检查存在其他文件的既有错误，完整部署模拟受 macOS 命令兼容影响未跑完，不能写成全仓所有检查通过。

曾通过 Source Map 对比得到主包中的 services 模块由 9 个变为 0 个。这是当时构建快照的模块归属计数，不能换算为体积、速度或安全提升百分比；当前简历保留定性结果。

本次采用“登录依赖与发布检查”作为条目标题，呈现已经实现的前端工程治理。后端逐请求鉴权、角色与数据权限校验、Nginx 静态资源会话校验，以及固定公开与私有资源路径，仍属于该对话中的讨论或建议，不能写成已落地。代码也不能保证所有接口集中在唯一异步包。

分包控制加载时机；接口路径仍可从浏览器代码分析或直接下载的静态文件中获得。禁用 Source Map 限制通过源码映射获取原始源码，不能使已发送到浏览器的 JavaScript 保密。因此，本条没有使用“防止接口泄漏”“完成权限系统设计”“彻底解决越权”或“保证未登录无法下载业务 JS”等表述。

这个案例补充了后台部分原先缺少的具体工程选择，现作为独立后台项目的第四条，其他业务与通信案例也保留。后续面试可围绕依赖为什么进入登录阶段、为什么保留会话检查、怎样核对构建产物，以及前端加载和服务端权限的边界展开；个人对各项改动的掌握程度和真实上线结果仍需分别确认。

后台与 PDA 恢复独立项目的依据

本人在 2026-10-08 指出，后台与 PDA 的很多工作在精简后看不见，广播模式也未写入。这个反馈说明原先合并为三条的容量不足以呈现两个项目的差异。本次恢复独立项目及代表工作，不恢复每一个页面、字段和常规按钮的完整清单。

后台除旧简历记录外，本次只读核对当前代码，可确认以下实现：

包裹分包弹窗支持基于 React DnD 的拖拽与扫码分配，扫码时提示重复分配；提交前检查未分配包裹及空箱。这是仓储业务中的分箱，与前端代码按需加载分包是两个案例。
JsBarcode 工具生成 Code 128 条码，作业列表支持选中批量打印或补打。
ChatBox、消息展示组件接入全局 WebSocket，处理订阅、重连和退出清理，采购订单也有联系客户的入口。
退款有批量审核和驳回，财务记录支持导出；ECharts 作业绩效覆盖验货、拍照、上架、拣货和打包等阶段。

这些内容恢复为简历中的具体做法，未新增个人主导、效率提升或权限安全保证。2026-10-08 的 PDA 表述主要沿用原简历，当日未核对 PDA 源码；2026-10-09 的补充依据见下节，不把后台代码当作 PDA 实现证据。

2026-10-09 PDA 本地代码补充

2026-10-08，本人要求：“广播模式你可以先保留上下文，等我切电脑的时候在补充。”2026-10-09，本人提供 C:\work\bbdbuy-pda-uniapp 并要求补充 PDA 项目，现已完成代码层面的只读核对和简历更新。此前“广播模式待补”的记录保留为历史来源，当前待确认的是个人职责、实际验证及上线结果。

以下文件路径均相对于上述来源仓库，仅记录实现定位，不复制公司源码、业务地址或账号配置。本次未运行该仓库、执行其测试、调用业务接口或连接 PDA。

广播扫码与上架作业

硬件接入与生命周期： hooks/scanner/usePdaBroadcastScanner.js 通过 Native.js 调用 Android 广播 API，支持协议参数覆盖；页面显示时注册，隐藏或销毁时注销。只有收到有效厂商条码后才标记广播就绪，不能把注册成功当作设备支持证明。hooks/putaway/usePdaBroadcastScanner.js 是入库上架专用实现，也按页面生命周期释放监听。代码包含按 targetSdkVersion 选择接收器注册参数的分支。
统一入口的实际覆盖： hooks/scanner/useUnifiedScanner.js 汇合输入框、相机与广播，统一去空白、同码时间窗去重、请求锁及焦点管理；当前接入点是 pages/warehouse-inbound/receive/receive.vue。入库上架使用专门的 usePutawayFlow，其他多个页面仍使用 hooks/useScanner.js 和 hooks/useSubmit.js，不写成全项目已迁移到同一个 Hook。
单件状态与结果待确认： hooks/putaway/usePutawayFlow.js 区分 ready、processing、error，先扫货位再扫包裹，提交绑定当次货位快照。处理中、异常未处理等状态拒绝新码且不排队；超时、断链或部分网关错误归为结果待确认，提示后端可能已完成，由操作员核对。这里没有自动查询后端核对上架结果的实现。
重试、留痕与计件： 人工重试复用原条码、货位快照、请求编号和会话记录；被拦截的 PDA 广播记为未提交及具体原因。utils/putawayLog.ts 按日分片保存本机日志；components/PutawayWorkbench/PutawayWorkbench.vue 展示成功、待处理、已处理和成功货位等会话统计。人工标记异常已处理只释放本地流程，不改写为上架成功；统计不是仓库全局产量。

来源定位：公共广播 Hook 第 80、99、137、159 行；统一扫码 Hook 第 124、203、251 行；收货页第 115 行；上架 Flow 第 780、931、956、1239、1279、1520、1555 行；上架日志第 62、155、170 行；工作台第 320、371 行。

媒体上传、水印与失败恢复

商品媒体组件： components/ImageUploadSection/ImageUploadSection.vue 被商品主图、详情图和 QC 照片复用，支持相机与相册入口、图片大小和扩展名限制、视频大小和时长限制、限并发任务队列、上传进度、超时取消、手动重试与删除时取消任务。图片、视频预览由 pages/products/list/list.vue 配合实现；不把视频扩展名配置写为已经执行的校验。
拍照与水印： pages/warehouse-inbound/inspect/inspect.vue 使用公共 ServiceMediaList 串行处理照片；入库配置为上一张处理完成后再重开相机。utils/watermark/drawWatermark.js 与 WatermarkCanvas 被入库、出库照片复用，按需归一化方向与尺寸，导出 JPEG。入库水印包含二维码、时间、重量、Logo 和操作人；时间来自本机，不能称为服务端时间。图片压缩在水印预处理，不是商品组件统一执行的步骤。
上传与登记分开恢复： utils/oss.ts 对凭证失效刷新一次，对网络、429 和 5xx 等指定错误有限重传。入库照片上传后按最终 JPEG 类型和实际字节数登记；utils/photoUploadRecovery.js 在登记结果未知时先查询同一 URL，避免盲目重复登记。失败任务保留在当前页面内供重试，未完成任务阻止业务提交；不写成跨重启恢复、离线队列、断点续传或后端严格幂等。
资源清理与验证材料： 入库在 finally 清理自行生成的水印 JPEG；压缩图和二维码临时图未显式删除，不能写为完整清理全部临时资源。仓库有水印导出、登记未知恢复、拍照顺序及压测执行器的测试文件，但本次未执行。docs/inbound-photo-stress.md 明确压测面板当前未挂载；可选 1000 轮不代表已完成真实千次压测，未将成功率、耗时、内存或吞吐量写为成果。

来源定位：商品媒体组件第 251、306、374、460、536、583、634 行；商品页第 56、71、88、276 行；入库拍照页第 34、97、104、205、221、239 行；媒体列表第 191、203、377、400、555 行；utils/image.ts 第 13 行；utils/oss.ts 第 53、97 行；拍照压测文档“压力测试组件（当前未挂载）”。

请求诊断与 WGT 更新

services/request.ts 默认只对允许的方法及网络、超时类错误自动重试；写请求需要显式开启。上架服务开启有限重试，发送 Idempotent-Id，自动和人工重试复用原编号。客户端行为可以核对，服务端是否正确实现幂等不能仅凭注释确认，不使用“保证不重复上架”等结论。

以上为 2026-10-09 仅据代码核对的边界。2026-10-21 本人已补充确认 PDA 的具体行为：首次因网络问题未收到响应，重试使用相同请求 ID，后端返回相同响应；该场景不再仅按注释或待确认记录，详见同日“写入重试规划与 PDA 幂等确认”。

utils/requestLog.ts 将错误、慢请求和重试恢复等记录保存到本机，包含请求编号、耗时与次数；按部分敏感字段名递归遮罩。URL、错误信息等字符串不一定被遮罩，因此简历使用“本机诊断并遮罩部分敏感字段”，不写“全面脱敏”。utils/requestLoading.js 按请求独立持有和释放加载锁，并提供订阅；不是所有请求都会加交互锁，需由调用方配置。

utils/update.js 和首页实现 WGT 自动或手动检查、确认下载、原生安装。静默参数只隐藏检查阶段提示，发现新版本仍需确认；普通安装等待下次冷启动，必要更新安装后确认重启。未核实包校验、回滚和 APK 分流能力，不将原简历的“静默更新”扩写成完整静默热更新体系。

来源定位：请求层第 93、117、124、164、210 行；上架服务 services/warehouse-inbound.ts 第 219 行；诊断日志第 42、62、114 行；加载锁第 25 行；更新模块第 103、123、167、192、210 行；首页第 211、271 行。

采用的表述与待确认项

2026-10-09 的 PDA 正文分为五条，使广播硬件接入、现场作业状态、商品媒体、拍照恢复和请求更新各有具体依据，当日技术栈补入 Native.js、Canvas 和 OSS。2026-10-13 又新增原生水印模块及 UTS，当前为六条，补充依据见下节。没有新增项目起止时间、个人独立主导、设备覆盖或效率数字。

代码注释称 Mobydata M63 已实机验证，也称服务端支持幂等；本次仅能记录这些注释存在。仍需本人补充：实际负责哪些设计、实现与验证，哪些设备和 Android 版本确实测试过，是否已上线，以及是否保留真实连续扫码、上传或故障恢复记录。设备型号与协议实现不再是完全未知，但本次没有新的实机验证结论。服务端幂等的后续本人确认见 2026-10-21 补充，其他未确认事项不因此解决。

2026-10-13 UTS 原生水印模块补充

本人补充 PDA 做了对接苹果与安卓的图片水印处理，并要求直接查看代码。本次只读核对 C:\work\bbdbuy-pda-uniapp，技术名称确认为 UTS。uni_modules/bbd-oss-mobile 当前实际是本地原生水印模块，目录名沿用旧命名；当前插件不包含 OSS 原生 SDK，上传与回显由 JS 控制器使用 uni-app API 完成。

本人随后于 2026-10-13 明确确认：“当前已经实现，测试已经跑通没啥问题。”本模块按已实现、测试跑通记录。源码文档此前的未测试说明不再代表最新验证状态；测试结果来源为本人陈述，本次代码核对没有重新执行原生测试。

原生接口与图片处理： 两端 index.uts 提供能力查询、调用及取消入口，桥接 Android Kotlin 与 iOS Swift。原生模块支持本地照片合成及任务输出删除；Android 使用 Bitmap / Canvas 和 ZXing，iOS 使用 ImageIO / Core Graphics / CoreText / CoreImage，完成方向校正、二维码、文字及 Logo 水印合成。桥接只传本地文件路径和少量水印字段。
编码与资源管理： 两端保留方向校正后的原像素尺寸，生成缩略图，并按目标体积和最低质量最多尝试四次 JPEG 编码。当前调试页采用软目标，达到最低质量后仍可超过目标；原生接口也支持严格上限，不将当前配置写成无损压缩或保证压到固定大小。原生侧串行处理任务，提供取消、任务输出清理及阶段耗时；取消不等于立即中断正在执行的图片编码。
调试链路： nativeWatermarkLabController.js 串行安排合成，另行管理上传、结果校验与回显，支持连续拍照、失败重试、取消和退出清理。原生输出以文件路径交给 uni.uploadFile，不通过 Base64 传输照片；耗时与质量信息用于观察，不是已经取得的性能提升数据。
接入与验证范围： 本次代码快照中的入口是 pages/debug/native-watermark/native-watermark.vue，开发环境首页的“原生水印测试”可进入；入库验货和出库打包仍调用 drawPhotoWatermark / WatermarkCanvas。保留原 Canvas 条目，原生模块单列为已实现并完成功能验证的经历。本人已确认测试跑通，具体设备、系统版本、测试方式及正式业务接入、上线范围未单独记录。

来源定位：模块 README.md 第 5、15、19、25、37 行；两端 utssdk/app-android/index.uts 与 utssdk/app-ios/index.uts；utils/nativeWatermarkBridge.js 第 3、31 行；utils/nativeWatermarkLabController.js 第 99、105、382、404、495 行；入库 pages/warehouse-inbound/inspect/inspect.vue 第 62、64、282 行；出库 pages/warehouse-outbound/pack/pack.vue 第 45、46、61 行。原生实现文件为 Android 的 NativeWatermark.kt、MobileCardRenderer.kt 与 iOS 的 NativeWatermark.swift、IOSLocalWatermarkPhoto.swift、IOSWatermarkCard.swift。

简历已新增“原生水印模块”条目，在 PDA 技术栈和移动端技术能力补入 UTS，并根据本人最新确认写明完成功能验证。后续如需展开面试案例，可补充具体方案选择、逐项实现责任、测试设备和范围；不将模块功能验证自动扩大为整个 PDA 的 iOS 适配、线上替换或 Kotlin / Swift 熟练度评级。

2026-10-17 简历正文完善

本人在新旧简历对比后明确，本次目标是完善简历。本次将已有资料支持的职责和技术细节直接用于正文，不将面试准备或新增验证任务作为改稿的前置条件。

职业概述： 提前呈现承担主要前端建设、前期唯一前端及招聘带教等已确认的协作职责，保留工程师岗位名称；技能栏减少与项目聊天条目的机制重复，仍保留六个领域。
三端工程与公共请求： 明确 PC、H5、RN 的共享业务和端侧 UI、路由、平台适配边界；依据职业资料的公共请求层记录，补清共享业务与 Axios 解耦、需登录请求的并发 401 处理及策略测试覆盖范围。不将这些表述扩展为所有端完全移除 Axios、全部测试由本人独立编写或本次重新运行测试通过。
构建发布： 从旧简历中恢复与现有原子切换、多环境构建和 OTA 兼容对应的实现细节，包括版本目录、软链接、Profile、Runtime Version 和 OTA Channel。个人逐项职责仍沿用前述来源边界，本次未重新核对公司仓库或新增上线结果。
后台与 PDA： 依据既有本地核对记录，补清登录依赖拆分时保留会话识别、制品残留检查失败，以及广播统一入口的收货流程范围。上架状态控制补清货位快照、新码拦截留痕与结果待确认；入库照片恢复补清未完成任务阻止业务提交。上架结果待确认不写成自动查询恢复，入库照片登记未知才沿用先查询核对的实现。
内容保留与事实边界： 四个项目及 SKU、聊天、原生水印等代表案例继续保留；原生模块维持已实现并完成功能验证的表述。没有新增业务规模、效率百分比、教育日期、正式管理职级或未经确认的生产接入结果，旧版存档保持原文。

本节记录文字取舍及既有来源，不构成个人职责、测试设备、业务数据或线上效果的新确认。

2026-10-17 基本信息调整

本人确认“我现在 26”，并要求在基本信息中增加年龄。当前简历加入“26 岁”，年龄来源为本人于 2026-10-17 的明确陈述，后续随投递时间核对更新。

页首只保留姓名，删除与求职方向重复的岗位称谓；求职方向单列，将“所在地”调整为“现居深圳”，并提前呈现已确认的本科与软件工程专业。学校仍保留在教育经历，未新增工作年限、求职状态、到岗时间或薪资信息。

2026-10-17 职业概述调整

本人认可本轮职业概述建议稿，已将该稿写入简历。概述以跨境电商业务背景、主要前端建设范围和工程实践为重点，简述带教、技术方案把关与代码评审经历；前期唯一前端、团队由 1 人扩充至 3 人、招聘及任务分配等具体信息继续保留在工作经历，减少两处完整复述。

本次仅调整已记录经历的组织与措辞，不新增工作年限、职级、业务指标或个人熟练度评级。

2026-10-17 求职方向澄清

本人明确表示求职意向没有特别偏向 RN，“React 技术栈即可”，并指出原“高级前端开发工程师（React / React Native）”定位“hold 不住”。当时据此将求职方向调整为“前端开发工程师（React）”；同日后续澄清见下节，当前以不带技术栈限定的“前端开发工程师”为准。

后续技术能力与项目取舍以 React 前端开发为主线，RN 继续作为已有多端项目经验呈现，不默认作为优先求职方向，也不额外使用高级或负责人定位。此前按 React / RN 方向记录的排序理由属于历史编辑依据，需结合本次澄清使用；本次没有修改既有项目事实或确认新的技能熟练度。

2026-10-17 求职方向与技能分类补充

本人进一步表示，技术能力中特地写“React 开发”没有必要，求职方向也可以不带 React。页首据此调整为“求职方向：前端开发工程师”。React 及其他已有技术继续在技术能力和项目经历中呈现，不将岗位名称限制为某一框架。

后续技能按 Web 开发、状态与通信、工程化、测试发布、跨端与设备应用及 AI 协作等能力范围组织，不单独设置“React 开发”类别。此时仅明确定位与分类偏好，后续六条建议稿的写入见下节。

2026-10-17 技术能力调整

本人认可本轮六条建议稿并要求“先改一版”，已按确认稿写入技术能力。顺序调整为 Web 开发、状态请求与通信、工程化与复用、测试与发布、跨端与设备应用、AI 协作。

Web 条目区分框架与界面工具，并依据现有 TMS 和后台素材补入复杂表格、批量录入与 ECharts 数据可视化实践；请求与通信条目保留缓存、客户端状态、登录与账号切换，概括 WebSocket 连接和消息处理。工程条目将内部层名清单概括为共享业务与类型；测试发布内容保留，跨端设备经验后置，技能栏不再逐项列出 Expo Router 和 NativeWind。AI 协作继续保留开发及核验方式。

本次为已有项目素材的归纳和表达调整，不将编辑确认扩大为全部技能熟练度、逐项独立主导或新增上线结果的确认。项目正文、历史来源及待核实边界继续保留。

2026-10-17 Handsontable 经历弱化

本人表示 Handsontable 相关内容“已经忘得差不多了”，希望弱化或移除。该轮调整从 Web 技术能力中移除由该经历归纳的复杂表格、批量录入表述；ECharts 收紧为展示业务统计数据。随后补入的 BBD 后台嵌套表格经历见下节。

TMS 技术栈移除 Handsontable，项目条目简化为参与业务页面、配置化表格及公共组件开发，不再展开该库的复制粘贴、下拉选择与校验等功能。既往参与记录仍保留，历史简历存档及此前修改记录不覆盖；不从本次陈述推断其他技能的掌握程度。

2026-10-17 BBD 后台嵌套表格补充

本人补充 BBD 后台的电商表格存在“订单套商品，表格套表格”的结构。该经历曾补入技术能力，后台项目也增加了对应条目。后续本人询问是否需要在技术能力中具体体现，本轮将技能表述收回到业务页面与公共组件开发，订单与商品明细嵌套保留在后台项目中作为具体案例；表格经验来自 BBD 后台，而非已弱化的 Handsontable 经历。

本次仅记录本人明确描述的订单、商品层级及嵌套表格展示，不额外补造展开收起、跨层级勾选、批量操作联动、合并单元格、虚拟滚动或性能优化等细节。Handsontable 与其批量录入表述继续不列为当前重点技能。

2026-10-17 HeroUI 使用补充

本人明确确认在实际业务项目中持续使用过 HeroUI，当前已补入 Web 开发条目，与 Ant Design 一同作为组件库呈现，并与 Tailwind CSS 的样式用途区分。此前个人资料未记录该库，本次依据为本人这次明确陈述。

具体项目、使用版本及组件定制范围尚未提供，本轮不将 HeroUI 指定为某个项目的技术栈，也不额外推定熟练度或主题、无障碍等专项能力。

本人进一步说明，补充库名主要是希望展示多种 UI 库的使用经历；个人认为 C 端业务发展到后期，不依赖 UI 库反而更好。当前 Web 条目据此区分组件库使用、公共组件封装、样式开发与统计展示。有关 C 端依赖取舍的看法按本人技术偏好记录，不自动写成已完成去依赖改造、独立组件体系建设或所有 C 端场景均适用的结论。

2026-10-17 状态与请求条目粒度调整

本人询问“登录态与账号切换治理”是否需要放在技术能力中。本轮按技能概括能力范围、项目展开具体实践的分工，将该条概括为请求封装、鉴权与错误处理，保留 TanStack Query、Zustand 和 WebSocket 的用途说明。

该调整不否认已有登录与账号切换素材，也不新增具体缓存清理或旧请求处理实现。相关具体案例及个人职责仍按已有来源核实，后续需要展开时归入项目经历。

2026-10-17 技术能力整段复核

本轮按当前模块规则复核全部六条，调整两处：测试发布从“为关键流程补充”的项目动作改为测试与交付实践；跨端条目从具体水印模块成果概括为 UTS 原生图片处理与桥接，保留已知图片处理范围。

Web 的多组件库使用与公共组件封装、状态请求通信的能力概括、工程条目的共享业务与平台适配、RN / PDA 经验及 AI 核验方式继续保留。平台适配等可跨项目理解的能力边界不等同于具体业务实现步骤，不能只为精简而删去。项目中的测试、水印与其他实现案例继续作为依据，不新增技能熟练度或上线成果。

2026-10-17 工程化与复用条目精简

本人认可本轮建议稿，当前技能条目调整为“使用 pnpm / Turborepo 管理 Monorepo，具备共享业务与类型抽取、平台适配及跨端业务复用实践”。保留工程组织与复用能力，将路由、存储和原生能力等适配边界概括为平台适配，具体实现仍在项目素材中展开。本次为表达精简，不新增职责、熟练度或成果。

2026-10-17 状态管理工具职责表述调整

本人认可本轮建议稿，当前技能条目明确为 TanStack Query 管理接口数据与缓存、Zustand 管理客户端状态，避免将“服务端缓存”理解为后端缓存。请求封装、鉴权与错误处理，以及 WebSocket 连接管理与消息处理实践继续保留。本次仅澄清工具职责与措辞，不新增具体实现或熟练度声明。

2026-10-17 移动端与设备接入条目调整

本人认可本轮建议稿，将技能标题由“跨端与设备应用”调整为“移动端与设备接入”，与工程化及跨端业务复用的能力范围区分；将“影像采集上传”改为“图片与视频采集上传”，提升可读性。其余能力内容保留，本次仅调整标题与措辞，不新增技术、职责或熟练度声明。

2026-10-17 AI 协作规则补充

本人补充，曾为项目定义规则，业务开发会按规范进行；已做 UI 与业务分离，后续重写界面时，借助 AI 根据外包设计师提供的 Figma 设计生成 UI，并对使用体验表示满意。这些为本人本次直接陈述，不仅来自项目文档。

本人认可本轮建议，技能条目改为编写项目开发规则、使用 Codex 按规范辅助业务开发与重构，并保留代码审查、类型检查和测试核验方式。本轮用规则约束及业务开发概括替换原需求拆解与文档整理的用途清单，不否认此前使用经历。

Figma 设计稿实现可以作为通用能力写入技能，但本轮技能重点为规则约束与改动核验，UI 与业务分离及界面重写保留为对应项目的候选案例。具体项目、规则内容及改版范围尚未展开，不指定规则文件名、工具接入方式、设计还原度、效率数字或业务完全无需改动等结果。

2026-10-17 Git 技能补充

本人认可本轮建议并要求修改，在“工程化与复用”末尾补充“使用 Git 进行版本管理与团队协作”，概括版本管理与协作能力，不单独新增技能条目。本次未展开具体操作、分支策略或熟练度评级。

2026-10-17 技术能力查漏补充

本人认可补充“UI 与业务逻辑分离”，同时明确表示国际化和代码规范“都有做”，要求补入技能。UI 与业务分离此前已由本人确认；本轮国际化及代码规范的个人实践依据为本人这次直接陈述。

Web 条目补充国际化与多语言适配；工程化条目补充 UI 与业务逻辑分离，以及代码规范检查与提交校验实践，保持六条分类。代码规范检查与提交校验的概括对应上一轮候选说明及本人“都有做”的回应。技能仍概括通用能力，UI 重写过程及 Figma 设计稿实现继续保留为对应项目素材。

本次未指定国际化库、具体语言范围或代码检查工具配置细节，不新增熟练度、团队规范制定范围或量化效果。

2026-10-17 浏览器扩展经历定位

本人补充，浏览器扩展只做过一个，用于当时的旧系统，自己不认为属于特长。因此不将浏览器扩展开发补入当前技术能力；现有工作经历中的具体案例继续保留，用于说明过去解决实际问题的经历，不扩大为通用扩展开发熟练度。此次未修改简历正文。

本人随后明确，当时的旧系统是租用的第三方 SaaS 系统。后续表述应说明浏览器扩展是该系统的配套辅助工具，不将其理解为本人开发了 SaaS 系统。该案例适合以一句话保留在包包达工作经历中，具体技术实现不在工作栏展开。

本人认可该表述并要求优化，现已将工作经历中的浏览器扩展条目改为“针对当时租用的第三方 SaaS 系统缺少可用接口的问题，开发浏览器扩展，支持订单匹配、物流单号采集与批量回填”。本次收起 Manifest V3、具体平台名称及 SKU 等细节，保留问题、工具和用途；历史素材仍可追溯，不新增项目或技能条目。

2026-10-17 技能与项目对照建立

本人希望为当前技术能力建立上下文或扩展，将技能与后续项目经历串联起来，并询问是否应等项目完善后再做。本轮建立“简历技能与项目对照”初版，先对应现有六类技能与案例，再随项目修改同步维护，最后统一复核。

当前简历正文保留原有表达，通过关联阅读提供入口。对照页区分已有项目案例、本人已确认但项目待定位的素材，以及历史经历的当前定位；不将 HeroUI、国际化、UI 分离、代码规范或 AI 规则自动归入未确认的项目。

2026-10-17 包包达工作范围措辞调整

本人认可将第一条改为直接说明工作范围，当前写为“承担 BBDBUY 平台（PC、H5、React Native App）、运营后台及仓库 PDA 的主要前端建设与迭代”。该句不再重复强调“前期作为唯一前端”，第二条继续保留团队由 1 人扩充至 3 人及实际协作职责。

本次为语气与层次调整，不否认本人已确认的前期唯一前端背景，也不新增职责或职级。

2026-10-17 新智慧迁移职责更正

本人明确说明：“其实我没参与 MVC 那个改变。”此前旧简历及改稿中的“参与前端从传统 MVC 向 React / Umi 组件化架构迁移”不属于本人经历，当前简历已删除该归功，保留 TMS 业务后台、仓库 PDA H5 页面开发、业务迭代、接口联调及上线问题处理。

后续不再推荐将该迁移作为本人亮点或技能支撑，也不以项目采用 React / Umi 推定本人参与技术迁移。旧简历原文保留，并在页首追加职责更正；面试资料同步注明不将该迁移作为个人经历。本次更正不涉及 BBDBUY 的三端工程整合经历。

2026-10-19 BBDBUY 主项目源码复核与改写

本人要求重新读取 C:\work\bbdbuy 后再写一版项目经历，随后明确认可建议稿，并要求写入当前简历、同步本页与技能项目对照。本轮只读查看公司项目的工程结构、代表性业务源码、测试用例和发布记录；没有修改公司项目、安装依赖、运行构建或测试、调用业务接口或部署。

源码复核后的首版表达与排序

主项目调整为八条：三端工程整合、公共请求与会话治理、SKU 规格联动、结算流程管理、支付一致性、三端客服聊天、RN 兼容与稳定性、测试与构建发布。先呈现工程基础，再呈现商品、交易与通信，RN 排障作为多端经验后置，与本人当前未特别偏向 RN 的前端岗位方向一致。后台、PDA、TMS 和技术能力正文保持原有内容。本节保留源码复核首稿的取舍；当前表达及标题以后续“2026-10-19 BBDBUY 项目表达具体化”节为准。

保留分层名称并说明作用： API、Query、Flow 与端侧 business adapter 在当前源码中有实际接入，分别说明接口访问、数据缓存、业务编排及平台能力适配。保留这些名称，避免仅写“抽取公共逻辑”；业务条目侧重具体问题与处理，不重复罗列内部层名。三端工程条目补清 UI 与业务逻辑分离、公共语言资源及 PC/H5 Web 组件复用。
请求与会话合并呈现： 共享业务依赖 Request Client 合同，三端分别创建公共 Axios Transport 的独立实例，并非三端共享同一运行时或完全移除 Axios。读取 Query 的取消信号传至请求层，仅对可恢复错误有限重试；不把 HTTP 方法直接等同于读写语义，Mutation 不自动重试。并发 401 去重限于同一 App 运行时的一轮登录会话内的 required 请求，普通公开或可选登录请求不触发统一退出。补入账号切换时取消旧读取、清理 Query/Mutation 缓存，以及 RN 重建业务区域以释放旧订阅、占位数据和页面状态的处理。
SKU 保留具体规则： 继续保留有效组合映射（Path Map）、库存与数量约束，根据当前实现补入不同来源平台规格标识的兼容，不新增算法创新或性能结果。
结算与支付拆开： 结算以订单类型和预览标识隔离草稿及缓存，聚焦提交、取消和迟到回调的生命周期。支付以服务端预览为金额依据，选项变化后重新计价并立即阻止旧预览提交；同步提交锁只用于支付单创建，不泛化为所有结算动作都具备同步防重，也不推定服务端幂等。支付轮询超时表示结果仍需确认，不能写成支付失败；终态再刷新相关缓存。
聊天补清会话边界： 保留回显、回包去重、ACK 超时、失败重发与断线重连，补入历史请求取消及响应身份校验。有限重连和客户端消息处理不等于消息必达、无限重试或服务端去重保证。
RN 与交付收紧验证表述： RN 写为启动问题排查、引擎和编译配置调整、标签页重构，不写线上崩溃已经完全解决。Web 补入 standalone 独立制品，保留版本目录、软链接、健康检查及失败回退，不扩大为零停机保证。RN 保留 Profile、Runtime Version 与 OTA Channel；应用提审与发布范围沿用已有个人经历记录，不以操作手册存在作为新的逐项职责确认。

源码与记录入口

以下路径均相对于 C:\work\bbdbuy，行号为本轮只读快照定位，后续可能随代码变化；这里只记录实现入口，不复制公司源码、业务地址或账号配置。

核对范围	代表性依据
分层与端侧接入	`packages/business/src/runtime/business-runtime-types.ts:30`；`packages/business/src/product/product-detail/product-detail-api.ts:5`、`product-detail-query.ts:18`、`product-detail-flow.ts:64`；`apps/rn/hooks/business/product/product-detail-business.ts:36`；`packages/web-ui/README.md`；`packages/i18n/shared-messages.ts:36`
请求、取消与会话	`packages/request/src/axios-business-transport.ts:196`、`unauthorized-request-coordinator.ts:32`；`packages/business/src/internal/query-policies.ts:20`；`packages/business/src/auth/auth-query.ts:33`；`apps/rn/hooks/business/app-business-adapter.tsx:101`
SKU 规格规则	`packages/business/src/product/product-detail/product-sku.ts:86`、`:121`、`:146`、`:209`；`product-detail-flow.ts:161`
结算身份与生命周期	`packages/business/src/order/submit-order/submit-order-draft.ts:3`、`:114`、`:135`；`submit-order-query.ts:30`；`submit-order-lifecycle.ts:20`
支付预览与结果	`packages/business/src/payment/payment-flow.ts:188`、`:204`、`:273`；`payment-query.ts:29`、`:43`；`payment-result-flow.ts:68`
聊天消息与会话	`packages/business/src/chat/chat-flow.ts:172`、`:220`、`:278`、`:418`、`:441`、`:574`、`:683`
RN 排障与当前改造	`apps/rn/docs/RN_1_2_1_MAJOR_UPGRADE.md:76`、`:221`；`apps/rn/docs/ANDROID_ISSUES.md:298`、`:364`；`apps/rn/app.json:96`；`apps/rn/components/ui/SegmentedTabs.tsx:145`、`:223`
Web 与 RN 发布	`scripts/deploy/build-dev-artifacts.sh:55`、`:104`；`scripts/deploy/deploy-next-release.sh:65`、`:100`、`:271`；`apps/rn/docs/ENV_USAGE.md:9`、`:54`；`apps/rn/eas.json:7`

验证与个人贡献边界

请求协议、401 协调和取消重试、认证缓存、结算生命周期、支付预览及部分 PC/H5 流程均存在针对性测试用例，例如 packages/request/tests/axios-business-transport.test.mjs、packages/business/tests/auth/auth-query.test.mjs、packages/business/tests/submit-order-lifecycle.test.mjs、packages/business/tests/payment/payment-preview.test.mjs 和 e2e/pc/order/submit-order-flow.spec.ts。本轮只读取源码及断言，没有执行这些测试；不将“存在测试”写成“本轮全部通过”，也不扩大为 SKU、聊天 ACK 或重连已有完整自动化覆盖。测试编写与执行责任继续按已有来源分别判断。

RN 历史文档记录 Hermes 运行时与编译链对齐方案，但 iOS Release 新包验证仍有待办；Android 标签页单内容实例方案已在代码中落地，Release 与灰度验证仍待补充。旧稿笼统的“冷启动异常”在本轮改为有具体来源的启动崩溃排查，不把不同原生崩溃都归为同一已解决问题。

源码和测试能够支持当前实现及设计边界，不能单独证明本人逐项独立设计、编写全部测试或完成全部线上验收。本人认可本轮建议稿属于编辑确认；此前已明确确认的主要建设范围、公共请求优化及团队职责继续保留，不新增个人熟练度评级、量化收益或上线结果。HeroUI、Figma 界面重写、Git 和 AI 规则的个人具体范围，不仅凭仓库配置或相似实现自动扩大；相关索引继续区分已定位实现和待明确的个人承担环节。

2026-10-19 BBDBUY 项目表达具体化

本人反馈“草稿隔离”等表述难以立即理解，讨论后认可“具体、专业、读一遍就能懂”的语言，要求重新改写。本轮调整 BBDBUY 的八条正文并同步技能与项目对照，保留原有案例及已核对的技术做法。

当前标题为三端工程整合、公共请求与登录处理、SKU 规格联动、结算流程、支付流程、三端客服聊天、RN 兼容与稳定性、测试与构建发布。“公共请求与会话治理”“结算流程管理”“支付一致性”三个旧标题分别调整为更直接的业务或工作名称。API、Query、Flow、business adapter、Request Client、Path Map、ACK、EAS 等必要技术名继续保留，并结合用途说明，不把易读等同于删除技术内容。

具体表述按“什么情况下，做了什么，处理什么问题”组织，不强制每条都套用固定句式：

请求与账号： “旧账号订阅与页面状态残留”改为退出或切换账号时取消旧查询、清理账号缓存并重置相关页面状态，避免继续显示上个账号的数据。RN 重新挂载业务区域属于对应的具体实现，源码入口和验证边界仍沿用上节，不再要求简历读者先理解订阅重建。
结算： “隔离草稿及缓存”改为按订单类型和预览编号区分每次结算，提交成功或取消时只清理对应数据；直接说明旧请求回调不能清掉新结算的数据，以及返回页面时不应继续使用已提交的预览。“草稿”在源码中主要指前端暂存的流程标识和编辑上下文，不扩大为完整商品、金额或跨重启恢复数据。
支付： “阻止旧预览提交、终态缓存刷新”改为修改支付选项后重新计价，金额确定前禁止提交，结果确定后刷新订单、运单与钱包数据。同步提交锁继续保留在支付单创建范围，超时后的动作表述为重新查询支付结果，不写成重新扣款或自动重试支付。
聊天： “响应身份校验、会话隔离”展开为切换聊天时取消旧历史查询，并核对返回结果所属会话；回显、回包去重和 ACK 超时改为消息发送、收到确认及失败重发的具体行为。
工程、RN 与交付： 说明 API、Query、Flow 的各自用途，把“单内容实例”展开为只渲染当前页内容、通过横向手势切换；发布描述按保存版本、切换版本、检查服务状态与失败回退展开。RN 问题继续写排查和改造，不新增线上验证结论。

前述对账号切换、结算和聊天的假设场景用于解释代码处理的风险，不自动记录为本人实际遇到的线上事故。本人此次认可语言调整，不构成对各项独立设计责任、历史故障、测试执行或业务收益的新确认；本轮未修改公司项目或运行其构建、测试、接口与部署。其他项目、技术能力正文、旧稿来源及待核实边界继续保留。

2026-10-19 平台规模与正式上线背景补充

本人表示，BBDBUY 是自己约三四年前端经历中最有分量的项目，并补充当前累计用户已达 16 万、今年 5 月从旧系统转向新系统。后续明确，“转向”指新系统于 2026 年 5 月正式上线并接替旧系统；用户来源中可能有旧系统用户，也有公司投流推广引入的用户。

本轮将正式上线月份和截至 2026 年 10 月的平台累计用户约 16 万补入 BBDBUY 项目简介，先交代业务规模与运行背景，再由八条项目工作说明技术做法。数字来源为本人于 2026-10-19 的最新陈述，本轮没有查询运营后台或独立核对统计报表。

16 万用于说明平台累计规模，不改写为活跃用户、付费用户、并发量或全部由新系统上线后新增的用户。旧系统用户是否及如何计入、注册及去重等统计口径、各来源占比尚未细化；公司投流推广是用户来源背景，不写为本人获客成果，也不把平台用户增长直接归因于前端改造。
2026 年 5 月是本人确认的新系统正式上线接替时间，不自动成为项目开发起点、所有端同时上线日期或本人独立完成数据迁移的证据。此前记录的 2026 年 7 月 Monorepo 整合完成属于后续工程演进，两个时间分别保留。
“最有分量”按本人对代表项目的评价记录，用于确定简历与后续讨论的重点；约三四年是本人的概述，不据此替换已更正的任职时间或新增精确工作年限。

本次补充属于项目背景，不新增技术熟练度、个人独立主导范围、迁移过程或量化收益；既有职责及验证边界仍按前文来源分别判断。

2026-10-19 整体建设范围与业务熟悉程度补充

本人进一步表示，BBDBUY 是自己一手写过来的，基本了解得很深，包括整套业务，并询问还有哪些亮点值得补充。这是本人对整体建设参与和业务熟悉程度的直接陈述，不仅来自项目源码。后续建议可更明确说明 PC、H5 与 RN 的整体前端建设范围，并用完整业务链条及具体方案取舍说明深度；不把“深入了解整套业务”单独写成泛泛自评，也不继续仅以零散模块参与描述本人的主要建设背景。

本轮曾继续询问正式上线接替旧系统时的个人承担内容，以及此前 Figma 界面重写的项目归属和范围；本人后续回答见下节。新陈述不自动扩大为全部后端、产品或数据迁移职责，也不将拟补充的案例、方案取舍或收益视为本人已确认。本轮记录背景，具体新增项目条目仍按讨论后的取舍处理。

2026-10-19 上线职责、真实故障与改版范围确认

本人补充上线初期基本由自己一人完成前端全部工作，包括开发、部署与自测；明确 PC 端几乎全部按 Figma 重写，M / RN 正在其他分支继续重写。本轮将这些本人陈述记入职业资料与技能项目对照，解决此前个人上线责任及 Figma 项目归属的待明确入口。自测不自动等于全部单元或端到端测试由本人独立编写，PC 已重写的范围也不扩大为三端重写全部完成。

本人认为多数前端业务在模式跑通后并非特别困难，SKU 与库存联动可以作为难点；支付主要难度在后端。后续选择亮点时，优先说明本人真实承担的交付范围、实际线上排障、RN 双端适配，以及已有架构在大范围界面改版中的应用。支付前端已有实践继续保留，但不包装为资金计算、分摊算法或账务系统建设，也不因难点偏好自动删除现有业务案例。

浏览器自动翻译引发的真实故障

本人确认曾发生线上故障：谷歌浏览器自动翻译页面后，React 重渲染崩溃报错，通过增加埋点才定位到原因。本人进一步说明处理办法是禁止浏览器自动翻译，避免翻译改动页面 DOM 后，React 更新找不到原有节点。该案例属于本人提供的真实排障经历，与此前用于解释账号切换、结算和聊天的假设场景区分。

当前 PC 的 apps/pc/app/layout.tsx:38、:55 与 M 的 apps/m/app/layout.tsx:57 可定位到 google: notranslate、根 HTML notranslate 和 translate="no" 等处理；站内多语言继续由原有国际化资源支持。此处不补造具体报错堆栈、复现设备、错误率或回归范围，也不将浏览器翻译提示配置扩大为强制阻止全部翻译插件。

本人确认有过通过埋点定位故障的经历，不等同于当前已经建设完整线上监控。现有 apps/pc/app/error.tsx:34 和 M 对应错误边界的 client-log 采集仅在开发环境启用；本地历史中曾有更早的采集实现。Sentry、采样和 Issue 聚合仍在 docs/REQUEST_ERROR_FEEDBACK_PLAN.md 中列为后续事项，不能仅因日志或计划存在写成当前统一线上监控平台已落地。

RN、Store 与设计 Token 的候选入口

RN 适配： 本人明确指出 iOS / Android 安全区和键盘遮挡等适配复杂。当前 apps/rn/components/common/safe-bottom-action-bar.tsx:12 处理底部安全区与重复留白；OverlayFlatList.tsx:278、:332 测量底栏高度并联动输入滚动及 KeyboardStickyView，退款与聊天页面已有接入。可补入 RN 条目，与已有 Hermes 和标签页排障区分具体场景，不新增全设备适配或线上崩溃消除结论。
状态分工： 仓库流程的服务端预览、服务目录、线路和费用由 Query 持有，Zustand 主要保留流程标识、地址与线路 ID、备注及用户选择的修改字段，搜索与弹窗等状态由页面持有。源码入口为 packages/business/src/warehouse/submit-warehouse/submit-warehouse-draft.ts:15、:189、submit-warehouse-query.ts:32 及 apps/m/hook/business/warehouse/submit-warehouse-business.ts:159。这是当前 App 会话中的跨路由状态，不写成跨刷新或跨重启恢复，也不推定全项目所有模块都采用同一模型。
界面重构与 Token： 已定位本人确认的 BBDBUY PC 大范围 Figma 界面重写，可结合复用已有业务层说明 UI 与业务分离的用途。packages/design-tokens/src/themes.ts、tokens.ts、web.ts、tailwind.ts 与构建脚本可核对到统一设计值、语义颜色、CSS Variables 和 Tailwind 预设，PC 根布局、Tailwind 配置和主题作用域已有消费者；当前 M 代码也有消费入口，RN 仍使用自己的 constants/theme.ts 映射，未依赖该 Token 包。不得写为三端完整统一设计系统、全部页面暗色完成或所有基础组件全量建设。

这些源码入口用于补充本人陈述和候选案例定位，本轮没有修改公司项目、切换其他分支、执行构建或测试、调用接口或重新验证线上故障。新增案例的篇幅与合并方式留待正文取舍，不将候选说明自动当作已写入简历的全部成果。

2026-10-19 develop 完整历史复核与候选素材

本人要求读取 C:\work\bbdbuy 的开发分支 Git 历史，寻找有意思的方案与项目亮点，并强调要看全部历史，不能只看一个提交。本地没有名为 dev 的分支，本轮以本地 develop 及缓存的 origin/develop 共同指向的 28f9cb7fe6a3400d6b29f3f16a268edf0ab88089 为固定查阅起点。该分支共有 601 条可达提交，包含合并记录；第一父链为 313 条，不能把提交数当成独立功能数或个人产出指标。

查阅范围与时间关系

逐条扫描完整提交记录和全历史变更路径，再按公共业务与状态、请求与主题、RN 交互与交付三组追踪相关历史，精选代表性 diff 并核对固定 develop 最终实现；不表示逐行审阅全部 601 个提交的所有 diff。范围为 2026-06-18 的 0389df7a（init）至 2026-10-17 的 28f9cb7f，没有 fetch 或确认远端最新状态。

三端于 6 月 21 日分别通过 bc9d7c85（PC）、a7270987（M）、8a559387（RN）迁入，属于工程快照导入；这条历史没有迁入前独立工程的逐步开发记录。因此 6 月不能作为项目开始日期，也不改变本人已确认的 5 月正式上线。当前工作区为 feature/h5-app-ui-refresh，本轮历史结论不把该分支截至 10 月 19 日尚未合入的改版当成 develop 成果。

整体演进为：6 月三端整合并开始逐域共享；7 月继续商品、订单、认证、钱包、聊天等业务复用及 RN 原生排障；8 月收敛状态、补齐交互与测试发布流程；9 月简化请求与认证/购物车接入、调整赠品流程并推进 PC 界面和主题改版；10 月继续支付、账单地址和媒体预览迭代。以下为值得进一步讲述的案例，不是新增的个人独立贡献或线上收益确认，也未自动写入求职简历正文。

值得保留的具体变化

历史线索	前后变化及可讲述的问题	建议归入
6 月 22 日 `b24d4aef` → 9 月 8 日 `9755f307`	先把购物车重复的请求、登录态和反馈能力收进根 Runtime，后又删除只增加透传的 hooks / action 工厂，让公共 Flow 直接读取 Runtime，端侧继续提供确认及导航差异。可以解释哪些业务值得共享、哪些抽象后来不再需要，不能把层数增加当成优势。	三端工程整合的面试展开
8 月 27 日 `620b9eaf` → 9 月 8 日 `1a1c44de`	语言/币种切换曾复用账号完整清理；后来改为取消旧读取、移除无订阅缓存、刷新活跃 Query，保留当前订阅和已有展示。退出或切换账号仍完整清理。说明根据变化来源处理数据，而不是所有全局变化都清空全部状态。	公共请求与登录处理；状态工具分工
9 月 4 日 `509d4021` → `00dea373`，后续 `9755f307` 仍保留	购物车修改数量成功或失败均重新查询，以接口确认数量与金额；数量组件曾在请求刚开始、进入 disabled 时立即恢复旧值，造成闪动，后改为在外部值更新或恢复可用时同步。区分用户正在输入的值、请求状态、服务端确认值，回源完成前不解锁。	SKU / 购物车数量与交易状态面试案例
9 月 9 日 `2447d39e`	赠品流程删掉本地 timer Store；M/RN 路由保留业务身份和 SKU 选择，候选、截止时间及领取资格回接口校准；返回详情、换批失败、关闭后迟到响应分别处理。本地计时到期由自动调用放弃改为结束展示并重新查询资格，避免页面计时替代后端权益判断。	业务理解与流程状态候选
9 月 11 日 `b93a884e` → 9 月 12 日 `4e1eeb7e` 及后续主题开放规则	语义 Token 生成 CSS Variables 与 Tailwind 预设；区分用户主题偏好与当前路由实际主题，已适配页面允许暗色，旧页保留浅色，返回新页恢复偏好。首屏脚本与客户端导航同步根主题，切换不以 key 重挂载业务树。适合结合本人确认的 PC 大范围 Figma 重写说明渐进改版用途。	UI 与业务分离、CSS Token、PC 改版候选
8 月 3 日 `012d272a`；8 月 22 日 `aae2bb65`	键盘适配通过测量实际底栏高度联动输入滚动和 KeyboardStickyView；横滑适配处理子图片/列表与父 Tab 抢手势，通过向父级传递触摸占用、多层计数及结束/取消/卸载释放，避免父级长期被锁。	RN 兼容与稳定性候选细节
8 月 4 日 `5d30ab8f` → `bea80cef` → `7d5f7651`；8 月 5 日 `1b0978c1`	dev 自动发布先补正公共包构建顺序，又处理制品和 current 已是新版本、同名 PM2 却沿用旧 script/cwd 的情况：检测旧入口后重建进程定义，正常后续发布再 reload，并单独处理首次迁移失败回退。随后新增生产 annotated Tag 验证和发布入口。可讲构建成功、制品正确与进程实际运行新版本需要分别核对；历史故障位于 dev，不直接称为生产事故。	测试与构建发布的具体排障例子
9 月 27 日 `a934f3ac`	商店强制更新检查优先，需要换原生包时阻断旧包操作，否则再检查 OTA，避免重复提示；处理正式应用身份、接口失败、非法版本、当前版本高于商店及回前台重新校准。	RN 构建发布的补充素材

固定 develop 代表入口：packages/business/src/cart/cart-query.ts、packages/web-ui/src/common/quantity-stepper.tsx、packages/business/src/global/localized-query-session.ts、packages/business/src/waybill/gift/、apps/pc/theme/、apps/rn/components/common/OverlayFlatList.tsx、apps/rn/components/ui/SegmentedTabs.tsx、scripts/deploy/deploy-next-release.sh、apps/rn/features/updatePop/AppUpdateCoordinator.tsx。这些路径属于固定历史快照，当前其他分支的同路径实现可能已变化。

后续改写需要避免沿用的过时信息

9 月 8 日购物车已删除部分旧工厂与合同文件；解释当前实现时不再把这些历史层次作为现存能力。
赠品旧 timer Store 已删除；本地会话标识和动作锁仅处理客户端状态，不能扩大为后端权益保证、并发库存锁或服务端幂等。
8 月 19 日 8ff47b07 的 RN 邀请链路修复仍可作为冷启动上下文案例，但之后认证重构将登录落点固定为首页；当前不能继续概括为 RN 登录后自动返回原商品页。
9 月 22 日 cc03445c 实际将 react-native-screens 4.26.2 升到 4.28.0、gesture-handler 2.31.2 升到 2.33.0；固定 develop 无对应 patchedDependencies。ANDROID_ISSUES.md 中仍有“4.26.2 回移补丁”的旧叙述，应以最终依赖及锁文件为准。Keyboard Controller 和 Reanimated 的相关升级规划不能当成已完成，更不能凭提交标题写崩溃或 ANR 全部消除。
Token 仍按实际 Web 消费范围说明；主题代码避免重挂载业务树，不等于全部页面和交互已完成实机、视觉或线上验收。

本轮只读取 Git 和源码，没有切换公司项目分支、修改代码、运行构建或测试、调用接口或部署。单元、mock 边界场景和真实 dev 主流程的测试代码用于确认已有验证思路，不新增本轮通过结果。简历取舍优先补充 PC 改版、RN 实际交互与发布排障，数量同步和赠品流程可供面试深入；不为覆盖历史功能而继续堆叠主项目条目。

2026-10-19 历史复核后的正文更新

完成 develop 完整历史复核后，本人追问“不用更新一下简历正文吗”，本轮据此将已经讨论的代表素材实际写入 BBDBUY 项目，并同步技能项目对照。历史复核节中“未写入正文”描述的是上一轮状态，当前采用情况以本节及对照页为准。

当前正文与取舍

项目简介保留 5 月正式上线、截至 10 月平台累计约 16 万用户的背景，增加个人职责行：“上线初期基本独立承担平台前端开发、部署与自测，后续持续负责三端迭代与工程整合。”该句依据本人已明确的初期全部前端责任，不扩大到后端、全部自动化测试编写或所有后续方案均由一人完成。

主项目由八条调整为十条：三端工程整合、PC 界面重构、公共请求与登录处理、SKU 规格联动、结算流程、支付流程、三端客服聊天、RN 兼容与稳定性、线上问题排查、测试与构建发布。新增条目各自承载有辨识度的案例，不为维持固定条数合并结算与支付，也不把所有历史功能都写进正文。

新增 PC 界面重构： 写入本人确认的 PC 绝大部分界面按 Figma 重写、借助 AI 并复用已有业务；结合源码已落地的语义 Token、CSS 变量、Tailwind 预设和按页面渐进接入主题。M/RN 重写仍在其他分支，不写成三端全部完成；主题切换不重挂载业务组件属于实现方式，不新增全量视觉或实机验收结论。
新增线上问题排查： 使用本人确认的浏览器自动翻译改动 DOM、React 重渲染崩溃、埋点定位与禁用自动翻译处理。它具有真实故障背景，独立于界面改版呈现；不扩大为完整监控平台、所有翻译插件均可阻止或新增故障率数字。
补强 RN 兼容与稳定性： 加入本人指出的安全区与键盘难点，以测量底栏、联动输入滚动和协调嵌套横滑说明做法；保留 Hermes 启动及 Android 标签页排障，具体 ViewPager2 / RecyclerView 名称收进面试素材，不重复堆积原生术语。依赖升级与未完成验证仍按历史复核边界说明。
补强测试与构建发布： 保留测试、Web 版本制品及回退、RN EAS 与应用提审发布，补入 dev 的 PM2 旧入口问题。Profile / Runtime Version / OTA Channel 的名称在正文概括为原生兼容版本与通道，配置细节及首次迁移回退仍在源码索引；不写生产事故或零停机结果。
概括工程与聊天表达： 三端工程仍保留 API / Query / Flow 及用途，端侧 business adapter 改用“各端适配路由、提示、支付及文件”等实际工作说明；未否定或删除已有分层实践。聊天缩短重复语句，保留本地回显、回包去重、ACK 超时重发及切会话时取消与校验的处理。

SKU、结算、支付原有独立案例继续保留，支付不因本人评价主要难度在后端而自动删除；购物车数量同步、语言币种刷新与账号退出区分、赠品流程、共享后简化工厂及商店强制更新协调等保留为面试或后续替换素材。未将源码中每个变化自动转为本人独立设计或新的线上成果。技术能力六类和其他项目本轮不扩写，技术栈仅补入本项目界面重构实际使用的 Tailwind CSS。

本轮只修改个人站点 Markdown，未修改或执行公司项目，也未新增投递、面试或计划完成记录。正文、上下文与技能项目对照分别保存当前表达、取舍来源及采用状态。

2026-10-20 BBDBUY 代表案例表达收紧

在固定编辑标准后，本人明确要求“继续项目经历得整改”。本轮据此处理前面已指出的局部信息密度，沿用 2026-10-19 版本的事实、结构和案例选择；不是因看到 GitHub 范文而否定旧版，也未更换评价标准。范围限 BBDBUY，其他项目、工作经历与技术能力正文保留。

保留内容

平台简介、5 月正式上线、截至 10 月累计约 16 万用户、上线初期基本独立开发部署自测，以及十个案例及其顺序全部保留。SKU 条目已经交代了规格组合、Path Map、来源标识与库存约束，本轮保持原文，不为体现改稿而换词。

三端整合继续说明共用业务与端侧界面、平台交互的分工；PC 改版紧接着说明在复用已有业务的基础上重写界面，体现前后工作的联系。没有补造三端原先每项需求都要重复开发、改版完全不动业务、复用率或效率数字等结果。

概括与保留的细节

条目	当前正文的重点	保留在上下文与面试素材的实现细节
三端工程整合	Monorepo、共用接口调用与查询缓存逻辑、业务流程，以及各端界面与平台交互	API / Query / Flow 的名称和分层、business adapter 与 Runtime 注入的路由、提示、支付、文件能力；共享的是代码与策略，不是三端共用同一运行时缓存。
PC 界面重构	Figma 重写范围、业务复用、Token 生成 CSS 变量及 Tailwind 预设、新旧页面渐进开放深色主题	当前路由实际主题与保存偏好的区分、首屏脚本与客户端同步、主题切换不重新挂载业务树。
公共请求与登录处理	响应、错误、取消、读写重试规则，同一会话需登录请求并发 401 去重，以及退出/换号清理	Request Client 与 Axios Transport 分离、错误分类、读取取消信号、required 请求范围及 RN 业务区域重挂载；不因正文概括改变这些边界。
结算与支付	每次结算身份及清理范围、服务端金额依据、重新计价与提交保护、查询和同步结果	结算数据生命周期与迟到回调的精确匹配、渠道/优惠/账单地址变更、同步锁限支付单创建；轮询超时仍是结果待确认，不是失败或重新扣款。
三端客服聊天	回显、去重、ACK 超时标记失败和重发、重连及切会话的查询处理	历史取消及响应身份核对；原有客户端保证范围保留，不扩大为服务端消息必达或无限重试。
RN 兼容与稳定性	安全区、键盘与底栏联动、嵌套横滑，以及启动和 Android 标签页崩溃排查与改造	底栏高度测量、触摸占用与释放、Hermes 运行时和编译链、ViewPager2 / RecyclerView 回收路径及各次依赖演进；未新增 Release / 灰度验证结论。
线上问题排查	埋点定位 Chrome 翻译改动 DOM 与 React 重渲染崩溃、PC/H5 禁用自动翻译	notranslate、translate=no 等根布局配置及历史 client-log 状态；不扩大为完整监控平台或所有第三方翻译插件均可阻止。
测试与构建发布	测试范围、CI/CD 与 EAS、Web 制品/版本切换/检查/回退、dev PM2 旧入口、应用提审及 OTA	standalone 目录、软链接、首次接管与正常发布的 PM2 区别及回退规则、Profile / Runtime Version / OTA Channel；源码存在与本轮执行结果仍分开。

本轮十条工作描述由 1408 字符收紧至 1205 字符（包含标题、空格及技术名称，仅供编辑比较，不作为能力或效率成果）。代价是正文不再展示所有内部名称、配置和条件；对应做法仍能通过本页历史来源及技能项目对照追溯。目的在于减少重复及连续并列规则，保留读者判断个人工作所需的具体内容，不把“更短”当成唯一合格标准。

当前十条标题与顺序未变，技能对照仅同步正文与面试细节的表达层级，不新增技能、个人贡献或业务结果。本轮修改为 Markdown 文案，检查内容一致性及 Git 差异格式，不执行公司项目或新增自动化测试。

2026-10-20 新系统订单与运单规模补充

本人补充“49w订单呢4.5w运单”，经询问范围，明确回答为“新系统上线至今的累计量”。据此将截至本轮 2026 年 10 月的新系统累计订单约 49 万、运单约 4.5 万补入项目简介，与 5 月正式上线及平台累计用户约 16 万一起说明业务背景。来源为本人本轮直接陈述，没有查询运营后台或独立核对报表。

49 万订单与 4.5 万运单的范围是新系统自 2026 年 5 月上线至今；不混作新旧系统合计。
16 万用户沿用平台累计口径，可能包含旧系统用户及公司投流引入用户；本次回答没有将其改为新系统上线后新增用户。
正文只写订单数、运单数；支付、取消、发货及签收等状态范围未单独说明，不改写为已支付订单、已完成履约或已发货运单，也不据此计算转化率、平均客单、并发量或性能指标。
三项数字用于交代项目规模，个人贡献继续由职责与案例说明。本轮补充属于有新事实依据的背景更新，不新增业务增长归因、后端处理能力或个人获客成果，十个项目案例及技能范围不变。

2026-10-20 项目业务简介概括

本人询问业务范围句是否需要保留，讨论后认可概括表达并要求修改。当前写为“业务覆盖商品代购、订单结算与支付、仓储合箱及国际物流，配套钱包、退款和客服功能”。简介保留主要业务链条，SKU、购物车和客服会话的具体处理继续由原有项目案例说明；这是已获认可的局部精简，不否定原句事实，不删除对应案例，也不改变上线时间、业务规模或个人职责。

2026-10-20 BBDBUY 八项重点提炼

本人确认技术栈部分没有问题，询问现有十条该保留多少、是否值得说的都写。讨论后明确认可按八个重点组织，并要求重新提炼。本轮为本人认可后的投递表达取舍，保留既有事实；此前十条完整版本及单项技术细节仍可通过本页历史记录与 Git 追溯，不将旧版判为不合格，也不把八条设为其他项目或所有岗位的硬性数量要求。

当前 BBDBUY 的八条及侧重如下：

顺序	当前条目	提炼方式与保留内容
1	三端工程整合与界面改版	以共享业务及其在后续界面改版中的使用串起两项工作；保留 Monorepo、共用接口/缓存逻辑/业务流程、端侧 UI 与适配、AI 辅助 Figma 重构及 Web Token 主题。根据下节同日补充，改版范围写为分阶段重构 PC、H5 与 RN；业务类型、多语言资源、PC/H5 公共组件、CSS Variables/Tailwind 预设和渐进主题边界保留为实现素材，不直接拼接两段清单。
2	公共请求与登录处理	保留已收紧的响应、错误、取消和读写重试规则，以及同会话 required 请求并发 401 去重、退出换号清理；不因合并其他条目而继续换词。
3	SKU 规格联动	原文保留，有效组合、Path Map、来源标识、库存及购买数量约束独立呈现。
4	结算与支付流程	按结算状态、金额确认与提交保护、支付结果查询组织，保留订单类型/预览编号、对应清理、服务端金额、计价期间禁提交、支付单防重、Web/RN 接入及结果同步。旧回调、返回已提交预览、选项变更及超时重新查询的完整细节留作面试；省略细节不改变实际行为，也不写资金算法或服务端保证。
5	三端客服聊天	保留回显、去重、ACK 失败重发、重连与切会话查询处理，独立支撑通信能力。
6	RN 兼容与稳定性	保留安全区、键盘、横滑，以及启动和标签页排障及改造，未新增实机或线上验证结论。
7	线上问题排查	保留本人确认的 Chrome 翻译与 React DOM 崩溃案例，独立体现真实排障。
8	测试与构建发布	用测试、Web 交付与故障回退、RN 发布三部分组织，保留 dev PM2 旧入口问题及应用提审、OTA 范围；分句说明，不补充工具清单。

首次提炼后的八条描述合计 1031 字符，较上一阶段十条的 1205 字符减少 174 字符（含标题、技术名、空格与换行，仅用于编辑比较，不是个人能力或效率指标）。当时合并后的两条分别为 156 与 139 字符，均重新组织重点，没有把原两段原样串接。其余独立且已清楚的案例保留原文；测试发布只调整分句与重点表述。

平台简介、5 月上线、49 万订单与 4.5 万运单的新系统范围、16 万平台累计用户、个人职责、技术栈及其他项目本轮均保留。技能对照同步为八条的新入口。今后追加素材仍先判断是否提供不同能力证据，不自动扩充正文条数；本轮没有新增事实、指标、个人独立责任或上线成果，也没有运行公司项目。

2026-10-20 第一条补充：三端界面改版范围

逐条复核时，本人提出改版经历不应只写 PC，H5 与 RN 后续也在复用业务的基础上进行 UI 重构；随后明确两端尚未全部写好。当前第一条据此改名为“三端工程整合与界面改版”，写为“借助 AI 按 Figma 设计稿分阶段重构 PC、H5 与 RN 界面”，同时呈现三端工作范围和当前分阶段实施的状态，不声称三端重构均已完成或上线。

设计来源沿用此前本人确认的外包设计师提供 Figma 设计稿、本人借助 AI 实现界面的记录；本次“根据外包人员写的”没有单独明确外包交付的是设计还是代码，不据此新增外包完成前端代码、本人接入业务的职责分工。PC 绝大部分已重写的既有确认、H5/RN 尚未全部完成的最新进度继续分别保留。Token 与渐进深色主题在正文明确限定 Web 端，RN 未统一接入该 Token 包的源码边界不变。

本轮只更新第一条及其来源、技能关联，其他七条、条目顺序、平台背景、技术栈和其他项目保留。

2026-10-21 移除旧版面试练习资料

本人在清理个人资料站时，要求移除依赖旧简历的面试资料。已删除「面试准备总览」「简历项目讲述与追问」「从简历扩展的前端基础与手写题」「求职面试练习材料」四份旧版衍生文档，并清理协作说明、四周求职计划及站点中的阅读入口和关联引用。

本轮仅移除旧版练习资料，不修改当前简历、已确认的个人经历或技能项目对照；2026-09 简历存档仍用于追溯原文。四周求职计划中的本人确认事项、历史建议及空白记录表继续保留，不因材料删除而标记任务完成，也未重新制定面试计划。

2026-10-21 第一条更新：移除旧主题表述与核对新样式方案

本人要求继续第一条，明确指出“在 Web 端通过设计 Token 管理样式并逐步开放深色主题”已经过时、没有必要保留；同时询问新的三端设计 Token 方案是否值得单独列项，并要求查看当前 PC 实现，说明后续会用于另外两端。本轮按明确要求从简历第一条删除该尾句，保留三端工程整合、业务复用及分阶段 Figma 界面重构。其他七条和技术能力正文不变。

只读核对 C:\work\bbdbuy 当前工作区 refactor/web-ui-source-consumption，与此前固定 develop@28f9cb7f 的历史快照区分。当前实现为：

PC 页面在 apps/pc/styles/globals.css 集中维护明暗语义颜色的 HSL 通道，apps/pc/tailwind.config.js 映射为页面使用的语义类，并在端侧维护圆角等配置。
apps/pc/styles/heroui.css 独立适配现有 HeroUI 控件颜色；页面配色不依赖组件库的主题生成，后续替换控件时可以移除这一适配层。
apps/pc/theme/theme-provider.tsx 接入 next-themes 管理根主题 class 与偏好，已不采用旧的按路由逐步开放模式。当前代码有全站统一主题状态，不等于全站视觉与交互已经验收。
共享 packages/design-tokens 及其生成链路仍保留，但当前 PC 不依赖、不导入，也不以该包构建为前置。H5、RN 保留各自现有实现；本人所述后续应用范围按计划记录，不写成三端已统一接入、配置共用或原生适配已完成。

实现与状态入口为 apps/pc/theme/README.md、docs/optimization/03-theme-and-design-tokens.md、packages/design-tokens/README.md，以及上述 PC 源码。当前方案文档标为实施中、PC 待验收；本轮未修改公司项目、运行其构建或测试、调用接口或部署，也不把新方案的代码存在推定为全部由本人独立设计或已取得线上效果。

本轮编辑建议是暂不增加独立项目条目：语义配色、页面样式与组件库适配解耦可以作为界面改版中的方案取舍展开，目前单列与既有改版案例有重叠，三端实际应用也尚未完成。此为本轮建议，不记录为本人已经认可该取舍；新方案保留为补充素材，后续若需要突出样式工程，可按实际完成范围重新判断。移除旧句不否定其历史实现，也不将“CSS 变量与 Tailwind 语义映射”本身评价为没有技术价值。

2026-10-21 第一条工具写法确认

本人询问 Turborepo、Monorepo 与 pnpm 的关系及斜杠含义，在比较详略后认可简洁写法并要求修改。第一条现采用“将三端独立工程整合为基于 pnpm + Turborepo 的 Monorepo”，保留后续共用业务、端侧适配和分阶段 Figma 界面重构；技术能力与主项目技术栈中的同一组合也统一使用加号，明确两种工具共同使用。

正文不增加工具职责的逐项解释，pnpm workspace 的依赖管理与 Turborepo 的任务编排留作面试展开。此为已获认可的措辞调整，不新增技能、个人独立职责、构建效率指标或三端改版完成结论；技能项目对照同步该表达。

2026-10-21 在项目正文旁补充编写规则

本人希望在项目经历内部也直接显示类似模块规则的说明，举出 BBDBUY 的项目简介、个人职责及第一条工程整合与界面改版，要求解释为什么写这些，避免下次回看时忘记。本轮在这些内容及相邻技术栈前加入 Markdown 引用块，沿用“目的、记录、不记录、理由”四项，保留原有经历正文。

简介规则解释服务对象、三端与多语言、上线时间、带时点的规模和主要业务链条各自提供的背景，并保留新系统订单/运单与平台用户的不同统计范围。职责规则解释为何需要单独说明个人范围及初期、后续的阶段差异。技术栈规则说明项目技术入口与技能栏的分工。第一条规则解释工程组织、共享边界与后续改版应用之间的联系，明确合在一条属于本案例的表达取舍，不是所有条目必须套用的模板。

这些规则属于简历编辑说明，不是新增的个人经历、能力、成果或逐项确认；未将自动化测试作者、全程独立、复用率、三端 UI 或 Token 全量完成等内容补为事实。其余七条和其他项目本轮未批量增加局部规则，后续随对应内容继续完善；技能项目对照只同步说明入口，不增加能力关联。原有通用模块规则和最新事实边界继续适用。

2026-10-21 第一条调整为整体前端架构概述

本人由数据流管理提出补充方向，进一步明确希望第一条先简述项目整体架构，让后续案例有共同背景；要求重新查看项目，并在讨论职责、依赖关系和平台边界后，明确授权按该思路修改第一条、编写规则与上下文。当前第一条更名为“三端前端架构与业务复用”，保留原有工程整合与界面改版事实，补清已核对实现中的分工。本轮没有新增独立的数据流条目，BBDBUY 仍为八条，其余七条、项目背景、个人职责、技术栈和技术能力正文不变。

第一条现在概括四方面：三端 Monorepo 与按领域组织的公共业务；接口访问、查询缓存与业务编排的分层；公共业务不直接依赖端侧 UI 和路由、由各端适配导航和平台能力；接口数据、需跨页保留的流程标识及用户编辑值、局部交互状态的不同归属。末句继续以复用业务分阶段重构三端界面作为实际应用，保留 AI 协作与 Figma 设计来源。此调整依据本人本轮明确的表达重点，不否定此前工程整合与改版合并版，也不将架构概述定为所有项目必须采用的模板。

本轮只读复核的实现入口包括 C:\work\bbdbuy 的 docs/ARCHITECTURE_OVERVIEW.md、packages/business/README.md、packages/business/src/runtime/business-runtime-types.ts、商品详情公共 API/Query/Flow 及三端 product-detail-business.ts、提交仓库草稿与 Flow，以及 packages/web-ui/README.md、公共表格和三端 i18n 接入。商品详情公共流程通过端侧传入的提示、结算跳转等能力供 PC/H5/RN 接入；仓库流程由 Query 持有预览、线路和服务目录，Store 保留标识与用户编辑覆盖值，再由 Flow 组合展示及提交参数。这些代表实现支撑正文中的分工概括，不等于逐行审阅全仓或确认所有模块完全一致。

当前解释与后续使用边界：

“前端架构”用于描述工程组织、职责、依赖、数据归属和平台隔离等结构设计；不据此新增架构师职级、全部方案由本人独立主导或已完成完整架构验收的结论。
共享的是业务代码与策略，不是三端共用同一份运行时缓存。Store 的跨页保留不等于跨刷新或跨重启恢复，也不表示所有输入都放入 Store；例如订单服务页的临时编辑仍在 Flow 局部状态中。
不依赖端侧 UI 和路由的范围限定公共业务层；PC/H5 仍有共享 Web UI，RN 保留原生界面。当前 Runtime 类型只含 request、auth、feedback，导航、支付等领域能力由端侧适配，不沿用旧注释将所有能力归进 Runtime。
公共 UI、多语言和更细的生命周期作为后续案例或面试素材，不把全部包名与内部能力名堆入第一条。未核实到 ESLint 自动限制包依赖越界，不写“通过 ESLint 强制架构边界”；旧主题尾句仍保持移除，新三端 Token 应用也不写成已完成。

第一条引用块同步说明为什么先写整体结构、为什么后续条目继续展开具体问题；技能项目对照同步新标题和数据分工的采用状态。本轮仅修改个人站点 Markdown，检查内容一致性与 Git 差异格式，未修改或运行公司项目、调用接口或部署，不新增个人独立贡献或上线收益。

2026-10-21 第二条复核与编写规则补充

本人要求继续查看“公共请求与登录处理”，同时补上编写规则，说明为什么保留这些内容。本轮依据项目模块规则、2026-09 本人确认的公共请求层经历及既有源码复核边界验收现稿：条目已明确三端共用策略、读写重试取舍、并发登录失效处理和退出换号清理，没有需要修正的事实或模块归属问题，正文保留，不为逐条复核继续换词。

在第二条正文前新增“目的、记录、不记录、理由”引用块。理由分别说明：统一响应与错误让三端按同一约定处理；读取在可恢复错误下有限重试，写入不自动重试，以兼顾恢复与自动重复提交风险；同会话需登录请求并发 401 时集中处理一次失效；账号变化时清理旧查询、缓存和页面状态，隔离前后会话。第一条负责整体架构概述，第二条以具体请求与会话规则展开，两者层次不同，保留独立条目。

既有边界继续适用：401 去重限同一 App 运行时的一轮登录会话内的 required 请求，公开及可选登录请求不触发统一退出；三端共享代码和规则，各自保有运行时与会话。读取取消、Query/Mutation 缓存清理不等于取消已经提交的写入；读写语义也不直接按 GET/POST 划分。风险说明不新增真实线上事故，客户端重试或提交规则不推导为后端权限、幂等、零重复提交或新的量化效果。

职业资料中本人已确认该轮公共请求层优化由自己完成，本轮保留这项确认，不因编辑措辞重新降为待推定；也不从测试代码存在补造本轮测试通过或全部测试独立编写的结论。技能项目对照同步第二条说明入口，其他正文及案例顺序不变。本轮仅修改个人站点 Markdown，核对内容一致性与差异格式，未运行公司项目或新增自动化测试。

2026-10-21 写入重试规划与 PDA 幂等确认

以下保留首次补充时的进度陈述与当时取舍；当前简历表达以后续“按本人要求将幂等重试并入当前项目”一节为准。

本人在回忆公共请求能力时补充：BBDBUY 计划支持带幂等处理的写入重试，但当前阶段尚未做好；PDA 项目已经实现过相应场景。具体描述为：第一次提交因网络问题没有收到响应，重试时携带相同请求 ID，后端返回相同响应。

这个场景的重点是首次请求结果不明确：未收到响应时，不能直接判断后端未执行。同一次业务操作的重试沿用原请求 ID，由后端识别并返回原响应，避免把重试当作新的提交。这里的请求 ID 用于该操作的幂等识别，不只是日志关联编号；不补造接口清单、编号有效期或后端存储方案。

BBDBUY：未完成规划。 将“写入重试与后端幂等配合”保留为第二条相关的后续方向，不写入已完成经历。当前正文继续保留“写入不自动重试”，既有读取有限重试、取消和会话处理的完成状态不变。
PDA：本人确认的已实现场景。 以本次本人陈述更新此前仅据客户端代码及注释、尚未确认后端行为的状态。原有请求编号复用的实现索引继续保留；本次未点明具体接口，不直接绑定为上架接口，也不扩大为全部接口的幂等保障、零重复提交或本人负责后端实现。

本轮只补充背景、来源与技能项目索引，不改 BBDBUY 或 PDA 的简历经历正文，也不自动新增技能熟练度。后续完善 PDA 条目时可采用这一已确认素材；本轮没有重新调用接口、执行设备测试或核验服务端实现。

2026-10-21 按本人要求将幂等重试并入当前项目

本人随后明确要求“在当前项目上直接当作是已经实现的功能”，并再次说明“你当作我已经实现就行了”。本轮据此将写入幂等重试并入 BBDBUY 的“公共请求与登录处理”，按已实现功能表达，不再在当前简历中列为后续规划。

正文区分读取有限重试与写入幂等重试：对支持幂等的写入接口，同一次提交重试复用请求 ID，由后端识别并返回原处理结果。原“写入不自动重试”不再作为该条当前表述；编写规则同步说明这个场景用于处理首次未收到响应后的重复提交问题，不扩大为全部写接口均支持幂等，也不增加后端实现职责、无限重试或零重复提交结论。

这次记录的是本人指定的简历表达；首次补充时的进度陈述保留在上一节，本轮没有新增代码核验、接口测试或上线验证。技能项目对照同步当前采用状态，后续改稿沿用本轮写法，不再仅依据上一节的旧取舍退回规划。

2026-10-21 第二条更新为公共请求与会话管理

本人在讨论第二条时提出，既然涉及登录，也应说明后端发放的 HttpOnly Cookie 与 PC/H5 服务端路由拦截，随后追问 RN 端的处理。只读核对三端后，先给出请求策略、平台准入和会话清理的合并建议稿；本人认可并要求先修改一版。本轮将第二条及引用块标题改为“公共请求与会话管理”，正文采用刚才的建议稿，不另增项目条目。

当前第二条分三组说明：统一响应、错误分类、读取取消与读写重试；PC/H5 接入后端 HttpOnly Cookie 会话并在服务端预检受保护路由，RN 结合用户信息查询与客户端路由守卫区分未登录和请求异常；同会话需登录请求并发 401 去重，以及退出换号时取消旧查询、清理缓存和页面状态。编写规则同步解释这些内容为什么保留，Cookie 参数、具体路由和跳转落点留作上下文与面试展开。第一条继续提供整体架构背景，第二条展开这项具体实践。

本轮讨论的实现与来源边界：

PC/H5： C:\work\bbdbuy\apps\pc\middleware.ts 与 apps/m/middleware.ts 读取登录 Cookie 的存在性，缺失时拦截受保护路由；两端根 app/layout.tsx 同样以该标记建立初始登录态。当前没有在这些位置核对到 JWT 验签或向后端验证会话的逻辑，因此正文使用“预检”，不写成完整身份或权限验证。HttpOnly 属性依据本人本次对后端会话约定的补充，不是从前端源码推定或本轮抓包验证。
RN： apps/rn/hooks/business/auth/use-auth-status.ts 依据用户资料 Query 区分加载、已有用户、游客与请求异常；use-auth-guard.ts 仅在稳定确认游客态后进入登录页。受保护布局 apps/rn/app/(protected)/_layout.tsx 在首次加载时阻断内容，在无法确认身份且请求失败时提供重试，不把网络异常当作未登录；use-auth-entry-guard.ts 让已登录用户离开认证入口。请求沿用公共 Transport，未发现 App 单独保存业务 Bearer Token 的实现，不新增原生 Cookie 持久化或 Token 管理成果。
账号变化： PC/H5 通过整页导航重建服务端登录快照和查询订阅；RN 的 apps/rn/hooks/business/app-business-adapter.tsx 在用户资料 Query 被清除时重建内层业务区域，释放旧订阅和页面状态。并发 401 的去重仍限定同一 App 会话内的需登录请求，公开及可选登录请求的原边界不变。

幂等重试继续沿用本人上一轮明确指定的简历表达，首次进度陈述及采用来源仍按前两节保留；本轮没有新增幂等实现、后端职责或验证结果。其他七条、技能正文和其他项目不变；技能项目对照更新标题与关联入口。本轮仅编辑个人站点 Markdown，检查内容一致性及差异格式，未修改公司项目、调用接口、运行设备测试或部署。

2026-10-21 第一条补充框架与各端职责

本人由 PC/H5 服务端登录处理进一步提出，框架选型与渲染方式也值得说明，询问应独立放在第一条之前还是并入第一条。在核对当前实现后，本人明确要求将框架选型和各端职责放在第一条开头，编写规则与上下文一起更新。本轮在“三端前端架构与业务复用”开头加入：PC/H5 基于 Next.js App Router，通过服务端布局初始化语言资源和登录标记；App 采用 React Native / Expo 覆盖 iOS、Android。后续工程整合、业务分层、端侧适配、数据归属和分阶段 Figma 改版的既有内容保留，不新增同级条目。

这个位置承接第一条作为整体架构概述的既有用途：先说明各端框架及职责，再说明公共工程怎样组织和复用。技术栈列表继续提供工具入口，第一条补充工具在本项目中的用途；第二条继续展开登录准入与会话处理，第一条不重复具体路由、401 或清理规则。引用块同步更新记录范围与理由，不要求其他项目照搬这一组织方式。

当前实现与渲染边界来自本轮讨论前的只读核对：

C:\work\bbdbuy\apps\pc\app\layout.tsx 与 C:\work\bbdbuy\apps\m\app\layout.tsx 使用服务端布局读取语言资源、Cookie 登录标记及币种上下文，再传给端侧 Provider。正文只选取语言资源和登录标记概括服务端职责，不将 Cookie 存在性判断扩大为会话有效性验证。
C:\work\bbdbuy\apps\pc\app\providers.tsx 与 C:\work\bbdbuy\apps\m\app\providers.tsx 的业务 Provider 初始 ready=false，在浏览器 useEffect 后设置为 true，之前返回 null；代表商品详情的数据通过公共 Query 在客户端获取。因此不能仅因采用 Next.js 就写“商品业务内容已通过 SSR 输出首屏”，也不新增已落地的 SSG/ISR 策略或首屏、SEO 收益。此判断依据挂载门槛和数据链路，不是简单将 use client 等同于没有服务端预渲染；部分服务端组件及 Metadata 的既有实现仍按各自范围保留。
C:\work\bbdbuy\apps\rn\README.md 与三端架构说明确认 RN/Expo 承载 iOS、Android 原生 App，移动 Web 由 H5 独立工程承载。公共业务与端侧 UI、路由及平台能力的边界继续沿用原有记录。

本轮采用的是已核对的框架与职责说明，不把框架的一般优点补写成本人当初的选型动机、独立选型职责或量化收益；若后续补充实际决策理由，再按本人陈述完善。技能项目对照同步框架分工和渲染边界；第二条及其余项目正文不变。本轮仅编辑个人站点 Markdown，检查内容一致性和差异格式，未修改或运行公司项目、调用业务接口或部署。

2026-10-21 Next.js、SSR、首页初始化与部署并发讨论

本人在理解第一条的“通过服务端布局初始化语言资源和登录标记”时，进一步讨论了 Next.js 的实际用途、SSR 与 SEO、SPA 拆包、Node 服务与业务后端的区别、PM2 实例及 PC 首页提前渲染的可能性。本人回忆当初选择 Next.js“可能”因为它属于 React 体系并有 SEO 能力；按不确定的回忆保存，不改写成已经确认的个人选型动机或独立决策经历。本轮最后要求先记录上下文，尚未要求改造公司项目或继续改简历。

服务端与请求链路

本项目这里的“服务端”主要指运行 Next.js 的 Node 服务；PC 默认端口 3000，H5 默认 3001，与提供账号、商品、订单、支付等接口的业务后端分工不同。浏览器负责客户端状态、Query 和交互，Next Node 负责服务端布局、Cookie 上下文、Metadata，并可按页面需要向业务后端取数、生成 HTML 或提供代理接口。

请求经过 Node 代理不等于 SSR：代理可以只把后端 JSON 转给浏览器，仍由浏览器渲染；SSR 是在服务端用数据生成页面 HTML。无需所有业务请求都经过 Next Node，也无需为使用 SSR 将订单、钱包等所有交互迁到服务端。当前 H5 的 /m/api Route Handler 仅在开发环境工作，生产业务 API 交给外层 /api 网关；这不能扩大为所有 PC/H5 接口都经过或都绕过 Node，实际线上分流本轮未连接服务器核验。

源码入口：C:\work\bbdbuy\apps\pc\app\layout.tsx、C:\work\bbdbuy\apps\m\app\layout.tsx、C:\work\bbdbuy\apps\pc\services\request.ts、C:\work\bbdbuy\apps\m\app\api\[...slug]\route.ts，以及 C:\work\bbdbuy\docs\PROD_DEPLOYMENT.md。

当前 ready 门槛的作用与代价

两端 Web 的全局 Store 先有默认语言和币种，是内存状态；当前没有使用 Zustand persist 等待 localStorage 恢复。根布局从 Cookie 读取用户偏好和登录标记，并准备翻译资源；登录标记仍只是 Cookie 存在性判断。
Provider 初始 ready=false，在浏览器 effect 中把服务端语言、币种初值写入 Store，再设为 true、挂载业务子树。请求层每次从 Store 读取语言和币种 Header，因此这个顺序能避免业务先按默认语境启动。这是当前依赖链所体现的保护作用，没有找到最初添加 ready 的直接历史说明，不将推断记作本人已经确认的原始动机。
ready 不等待远端汇率、IP 或登录请求。ConfigSync 在业务树放行后才挂载并启动汇率与 IP 语言币种查询；根 ready 与汇率确认状态是不同概念。
代价是根业务子树等到浏览器挂载后才显示，影响首页及业务正文的初始 HTML 输出。若后续希望同时保留正确初值和主体 SSR，需要一起调整状态注入与请求启动时机，不能只删除 return null；部分商品 Query Key 不包含语言、币种，单独更新 Store 也不天然保证重新取数。

相关入口：C:\work\bbdbuy\apps\pc\app\providers.tsx、C:\work\bbdbuy\apps\m\app\providers.tsx、C:\work\bbdbuy\apps\pc\store\global.ts、C:\work\bbdbuy\apps\pc\i18n\service.ts、C:\work\bbdbuy\apps\pc\services\request.ts，以及 C:\work\bbdbuy\apps\pc\hook\business\global\currency-business.ts、C:\work\bbdbuy\apps\pc\hook\business\global\language-currency-business.ts。

PC 首页与 SSR 的准确判断

PC 首页 page.tsx 是负责组合分区的服务端组件，主站布局及首页多数分区目前声明为客户端组件。客户端组件也可以先生成服务端 HTML，再在浏览器接管交互；客户端布局通过 children 容纳服务端组件，也不会自动改变后者身份。因此不能仅凭 use client 判断有没有 SSR，更不能把当前情况说成“服务端完全没有渲染”：根布局和 Metadata 已有服务端工作，首页组件也仍可能在 RSC 阶段执行并传送结果。当前阻碍首页主体首屏展示的是更外层 ready 门槛。

首页主视觉、公告、服务介绍和运营商品清单具备提前输出内容的条件；运营商品来自本地清单和参考价，不是实时商品报价。导航栏账号入口独立查询用户资料，加载时显示骨架，随后显示游客按钮或头像菜单；搜索、图片上传、服务项展开与分类滚动继续需要客户端交互。讨论中的可选分工是让公共内容提前输出，账号与复杂交互局部加载，尚未确定实施方案。

若首页正文在用户请求时由 Next Node 生成 HTML、在浏览器 JS 完成前可展示，即属于首页 SSR，不要求全站都采用 SSR，也不要求内容必须来自后端接口。构建时提前生成 HTML 属于静态预渲染；两者都能让初始 HTML 含有正文。当前 Next.js 为 15.3.6，根布局调用 cookies()，不能将现有首页整体称作构建时固定生成的 SSG 页面。

源码入口：C:\work\bbdbuy\apps\pc\app\(main)\page.tsx、C:\work\bbdbuy\apps\pc\app\(main)\layout.tsx、C:\work\bbdbuy\apps\pc\app\(main)\_components\home、C:\work\bbdbuy\apps\pc\app\(main)\_components\navbar\user-menu.tsx，以及前述根布局、Provider。以上为源码链路判断，未实际抓取生产首屏响应或验证性能。

SSR、SEO 与 SPA 的讨论边界

目前已使用 Next 的路由布局、服务端 Cookie 上下文、多语言及 Metadata 等能力；代表商品详情、搜索的数据主要由客户端 Flow/Query 获取，尚无商品业务服务端预取与缓存还原链路、明确 SSG/ISR 策略或首屏优化收益的证据。普通商品详情仍有登录门槛，商品内容的搜索收录需要先明确公开访问范围；根 Metadata、部分页面 canonical/Open Graph、robots/sitemap 的存在不等于商品 SEO 已完善。下载页有结构化数据源码，但同样处在 Provider 子树内，不能只凭源码声明初始 HTML 已输出完整正文及结构化脚本。

SSR 可以让用户和爬虫更早拿到内容，但不自动保证更快、减少全部客户端 JS 或获得搜索流量；交互仍需浏览器执行相应代码。SPA 描述客户端页面切换方式，不等于一个大包或首次下载全站代码，可以按路由、组件拆包和懒加载。实际首屏还受初始 JS、接口、图片与渲染等待影响，本轮没有生产首屏测量，不据此评价框架选型错误或补造性能数字。

PM2 与十万并发的讨论边界

本人记得服务使用 PM2、两个实例。本地部署配置默认 PC 为 bbdbuy-pc:3000、H5 为 bbdbuy-mb:3001，每个应用各两个 cluster worker；两端按默认完整部署时合计四个 Node 工作进程，数量可由环境变量覆盖。本轮没有查看线上 PM2，不能将默认配置当作当前真实实例数。发布流水线的并发次数也不是 PM2 worker 数。

Node 实例能够在异步等待网络时处理其他请求，两个实例不等于只能同时处理两个请求；转发 JSON、生成动态 HTML 和提供可缓存静态资源的成本不同。十万注册用户、在线用户及十万请求瞬时到达不是同一负载。若十万动态请求确实都到达 Node，这层仍要承受相应压力；当前没有机器容量、压测或线上流量证据，不能由实例数推导能够承受十万并发，也不新增高并发治理成果。

配置来源：C:\work\bbdbuy\scripts\deploy\standalone-ecosystem.config.cjs、C:\work\bbdbuy\scripts\deploy\deploy-next-release.sh、C:\work\bbdbuy\scripts\deploy\deploy-prod-release.sh 与部署文档。

本轮解释参考 Next 服务端与客户端组件、Next 15 Cookie 与动态渲染、Next 服务端取数与代理、React 懒加载、Google JavaScript SEO、Node 异步并发和 PM2 cluster。官方能力说明不作为本项目已实现或已获收益的证据。

本次只保存讨论及源码核对结果，简历正文不变；技能项目对照仅同步阅读入口。首页 SSR 是后续可讨论方向，不记作已接受的改造计划、已完成实践或新的熟练度确认。未修改公司源码、构建、调用业务接口、压测、连接服务器或部署。

2026-10-22 第一条补充 Next.js 选型依据与实际用途

本人继续昨天的讨论，提出先完善技术选型说明，让“为什么用 Next.js”与项目需求、实际用途对应起来；随后要求整理选型说明，并明确认可按该思路调整简历第一条、编写规则与上下文。本轮采用的是结合当前业务和实现进行的选型复盘，不将这次认可倒写成当初做过完整框架评估或已经确认全部原始动机；前一天关于 React 与 SEO 的不确定回忆仍按原来源保留。

选型依据与当前表达

BBDBUY 的 PC/H5 同时包含公共展示内容和登录后的交易业务，并需要多语言与币种偏好。当前认可的解释是：在 React / TypeScript 技术体系内，采用 Next.js 现成的路由、嵌套布局、页面元信息和服务端处理能力组织 Web 应用，同时为公共页面预渲染提供基础。Web 与 RN 的业务复用依靠公共业务分层及端侧适配，不归因于 Next.js 自动实现跨端复用；也不要求只有 Next.js 才能满足这些需求。

本轮初版将第一条开头改为：PC/H5 基于 React 技术体系，选用 Next.js App Router 组织路由与布局、管理页面元信息，并为公共页面预渲染提供基础；通过服务端布局初始化语言资源、币种偏好及登录标记。App 采用 React Native / Expo 覆盖 iOS、Android。后续 Monorepo、公共业务分层、平台适配、状态归属与分阶段 Figma 界面改版保持原有表达，不增独立条目。

“为公共页面预渲染提供基础”说明框架能力与选型考虑，不表示当前首页主体已输出完整首屏 HTML。编写规则同步区分选型依据、已有用途与待完善项；不新增独立选型主导、完整框架对比或 SSR/SEO 收益。服务端登录标记仍只是 Cookie 存在性判断，详细路由预检和会话规则继续放在第二条，不在第一条重复展开。

本人随后询问，这段作为技术选型简述是否足够、是否偏多。按原先“选型与各端职责”的范围，初版可以保留；若只承担框架选型简述，语言资源、币种偏好与登录标记的初始化属于可后移的实现细节。此处是依据本人进一步明确的详略偏好收短，不否定初版的事实与组织方式。

本人认可简述版后，当前开头采用：PC/H5 选用 React 体系的 Next.js App Router，统一组织路由、布局与页面元信息，并为公共页面预渲染提供基础；App 采用 React Native / Expo 覆盖 iOS、Android。编写规则同步限定框架部分的粒度，后半段工程组织与业务复用保持原文。初始化的已有实现及完整选型说明保留在下文，供后续阅读和面试展开；第二条不因此增加重复细节，原有 SSR 实现与收益边界继续有效。

已有实现的核对范围

2026-10-22 再次只读核对当前本地源码，现有用途包括：

PC/H5 的 App Router 页面与布局组织；根布局读取语言、币种和 JWTC Cookie 标记，准备翻译资源并向客户端传入初值。入口为 C:\work\bbdbuy\apps\pc\app\layout.tsx、C:\work\bbdbuy\apps\m\app\layout.tsx，以及对应的 i18n/service.ts。
两端 middleware 根据登录 Cookie 存在性预检页面准入，未在该层验签或查询后端会话。入口为两端 middleware.ts。业务后端负责真实认证和接口权限；客户端 Query 继续承担主要业务数据获取与交互更新。
根 Metadata 与页面语言已配置；下载页存在翻译后的标题、描述、canonical、Open Graph 及 JSON-LD 源码，另有 robots/sitemap。代表入口为 C:\work\bbdbuy\apps\pc\app\(main)\app\page.tsx 与 H5 对应下载页。元信息配置存在不等于正文或 JSON-LD 已完整进入初始 HTML，也不证明已获得搜索收录或流量收益。
standalone 制品和 PM2 部署配置已存在。部署配置说明当前框架有运行落点，具体实例数与线上容量仍沿用前一天的核对边界，不在本轮新增线上验证结论。

待完善方向与表达边界

以下是本轮选型说明中的后续建议；本人授权的是简历与说明文档调整，尚未授权实施公司项目改造，也不将建议列为已接受的具体开发计划或已完成能力：

优先让公共首页提前输出正文。 当前 PC/H5 根 Provider 的 ready 门槛仍等浏览器 effect 写入语言、币种后才挂载业务树。需要一起调整初值注入和请求启动时机，让首次渲染与后续请求使用正确偏好，不能只删除 return null。首页主视觉、公告、服务介绍和运营商品可作为优先范围；账号资料与搜索等交互局部处理。详细依赖与源码入口继续见前一天的初始化讨论。
先明确公开范围，再完善 SEO。 首页、帮助、下载页可先评估。普通商品详情仍有登录门槛，商品搜索收录需要先确定游客访问范围，再完善各页面的元信息、正文输出和站点地图，不由 SSR 自动推定 SEO 完成。
按页面明确渲染与缓存方式。 公共展示内容可评估预渲染与缓存；订单、钱包等个人业务继续按需要使用客户端 Query。当前 Next.js 15 根布局读取 Cookie，不能直接称为已实施 SSG/ISR；语言、币种与用户数据的区分需在具体方案中处理。
通过实际输出和测量验证效果。 改造后应检查原始 HTML 是否包含正文，再观察首屏展示、服务端响应和初始 JS 体积。本轮没有抓取生产响应、测量首屏、运行压测或验证搜索收录，不能添加性能或流量收益。

说明参考 Next 15 服务端与客户端组件、Next 15 Cookie 与动态渲染和 Google JavaScript SEO。官方文档说明框架与搜索机制，本项目落地范围以上述源码和本人陈述为准。

本轮只调整个人站点的简历第一条及编写规则、修改上下文和技能项目对照。第二条、其余项目条目与技能正文不变；未修改或运行公司项目、调用业务接口、部署或推送。

2026-10-22 第二条补充 Axios 与 TanStack Query 分工

本人继续复核“公共请求与会话管理”，指出正文没有交代 Query、Axios 等请求相关工具，询问是否需要补充；随后认可在开头用一句说明两者分工，并要求同步编写规则与上下文。此前正文已经保留响应、错误、取消、重试及会话规则，但过于侧重策略概括，将工具协作留在实现索引，没有充分检查第二条单独阅读时能否理解这些规则的技术依托。本轮补清工具与做法的关系，保留已认可的规则和范围。

第二条开头现采用：基于 Axios 封装三端公共请求层，统一响应解析与错误分类；结合 TanStack Query 管理查询缓存与取消，读取仅对可恢复错误有限重试。后续写入幂等重试、PC/H5 与 RN 的登录准入、同会话需登录请求并发 401 去重及退出换号清理沿用现稿。第一条继续说明数据归属，第二条解释请求工具怎样协作及采用哪些具体策略，Query 在两条中的用途不同，无需为去重删除其中一处。

随后本人要求先落实刚才提出的精简建议。本轮只合并开头“重试策略”与紧接的“有限重试”的重复表述，由具体读取规则表达重试策略；工具分工、可恢复错误条件、写入幂等及后续会话规则均保留。编写规则与技能项目对照同步这一措辞调整，不新增或删减功能范围。

技术依据与职责边界

本轮改稿依据前一轮讨论中的只读核对，代表入口为 C:\work\bbdbuy\packages\request\README.md、packages/request/src/axios-business-transport.ts、apps/pc/services/request.ts 和 packages/business/src/product/product-detail/product-detail-query.ts：

Axios 公共请求层负责实际 HTTP 传输、请求头、超时、响应解包和错误分类。三端复用 Transport 工厂和规则，各端创建自己的实例与会话协调器，不是三端共享同一个运行时。公共业务通过平台无关的 Request Client 调用，不直接依赖 Axios。
TanStack Query承接查询状态、缓存、失效更新、取消与读取重试策略。读取 Query 的 AbortSignal 经领域 API、Request Client 传入 Axios，底层消费信号后才能中止实际请求；不能将所有路由变化一概写成取消全部请求，也不将取消读取扩大为撤销已提交写入。
会话与端侧处理继续由协调器及上层边界配合完成。公共请求层识别并合并同一会话需登录请求的并发 401；登录跳转、查询缓存和账号状态清理由上层处理，不将全部能力归给 Axios 或 Query。

写入幂等重试继续沿用本人此前明确指定的正文表达，首次进度陈述与采用来源见 2026-10-21 对应记录；此次补充工具名不新增幂等实现、后端职责或接口验证结果。取消信号的通用机制参考 TanStack Query 取消说明，项目适用范围以本地实现与既有来源为准。

编写规则与后续复核

规则现明确记录请求传输与查询管理的协作，说明为什么需要保留工具名及用途，同时把通用工具原理、全部配置和内部调用链留作面试展开。后续复核同类条目时，先检查读者能否对应“必要工具、各自职责与具体做法”，再判断详略；不因为技术栈或第一条出现过某个名字，就机械省略当前案例所需的分工，也不要求每条都列完整工具清单。

此次只更新第二条及其编写规则、修改上下文和技能项目对照；第一条、其他案例及技能正文保持原有表达。未修改或运行公司代码，未新增测试、上线效果、个人熟练度评级或独立职责确认。

2026-10-22 第三条 SKU 规格联动复核与编写规则

本节保留当时的复核与表达取舍；来源兼容的判断已于 2026-10-23 纠正，最新正文及依据以“SKU 规格联动移除来源兼容表述”一节为准。

本人在确认前两条已经交代整体架构与公共运行机制后，要求继续检查第三条“SKU 规格联动”是否合适，并补充编写规则、说明为什么写这些。本轮按既有项目模块规则验收现稿，再只读核对当前本地 SKU 计算和商品详情 Flow：正文已经覆盖处理方式、来源适配、选择联动与购买约束，可以保留，不为逐条复核重新换词或堆入更多功能。此判断承接本人此前认为 SKU 与库存联动值得深入讲述的偏好，不新增独立算法设计或个人熟练度确认。

首次复核时保留的正文为：根据有库存 SKU 的有效规格组合构建 Path Map，兼容不同来源平台的规格标识；根据用户已选规格禁用无效或无库存选项，并在加购、立即购买前校验所选 SKU、起购量及库存上限。随后本人认可的方法细化见下文“同日补充位运算与组合索引方法”；该两版均为历史表达，最新来源兼容取舍见 2026-10-23 对应节。

内容用途与取舍（当时的复核判断）

新增的“目的、记录、不记录、理由”规则分别解释：

有效组合与 Path Map： 商品规格并非任意搭配，保留具体组合映射方法，说明怎样判断当前选择下哪些候选项可用。
不同来源的规格标识： 保留这项适配，说明案例涉及商品来源的数据差异，不只是在固定格式上渲染选项；字段名及每个兼容分支留作面试展开。
随选择更新禁用状态： 说明有效组合规则怎样体现在交互中，避免条目只剩算法名称。
加购与立即购买前的校验： 说明具体动作仍受完整 SKU、最低购买量和库存上限约束，不只依赖界面选项是否可点击。与下一条结算、支付的金额和流程处理各有范围。

这条作为第一个具体业务案例，重点是有效组合、来源差异及购买条件，不重复框架、Query/Axios 或完整商品详情功能清单。算法推导、复杂度、库存同步和收益数字不是本轮必补内容；未确认的算法原创、性能提升、后端库存保证及测试覆盖不能添加。

当前源码与数据边界

只读核对入口为 C:\work\bbdbuy\packages\business\src\product\product-detail\product-sku.ts 与同目录 product-detail-flow.ts；PC 接入见 C:\work\bbdbuy\apps\pc\hook\business\product\product-detail-business.ts。具体实现包括：

generateProductSkuPathDict 排除明确库存不大于零的 SKU，将规格子组合保存为属性值对和单独值 ID 两套索引；getSpecPropId 与 findSelectedProductSku 处理不同属性 ID 字段及匹配方式。
normalizeProductSkuPropList 初始化选项状态，applyProductSkuDisabledStatus 按当前选择逐个替换候选值并查询路径；Flow 的 changeSku 调用这些能力更新禁用状态。
getProductQuantityLimits 计算起购量、当前 SKU 库存上限和可购买标记，clampProductQuantity 约束数量；加购和立即购买动作都检查当前 SKU 与可购买标记，构建提交参数时再次约束数量。
正文概括主要规则，不表示接口总能返回完整库存。库存未返回时，当前路径计算仍保留该 SKU；库存缺失或无法解析时不设置前端数量上限。库存低于起购量时保留最低数量展示，由可购买标记阻止提交。这是基于当前详情数据的前端约束，不是提交前重新请求实时库存，更不证明锁库存或防超卖能力。

上述首次复核只新增第三条编写规则、修改上下文和技能项目索引，当时 SKU 正文及前两条保持原文。未修改或运行公司项目、调用业务接口、执行测试或新增线上效果；既有个人责任及核验范围继续按各自来源保留。

同日补充位运算与组合索引方法

本人随后询问第三条是否过于简单，回忆其中用了算法，并进一步明确认可将算法思路补进第三条、规则与上下文。原稿已经交代业务规则，本次根据本人希望突出具体处理方法而细化开头，不增加独立算法条目，也不否定原稿可以使用的判断。

再次只读核对 product-sku.ts 后，方法可准确概括为“位运算枚举规格的非空子集，再建立组合索引供候选判断时查表”。getAllCombinations 使用位掩码枚举非空子集，每一位表示一个规格项是否包含；generateProductSkuPathDict 将这些规格子集写入 Path Map，applyProductSkuDisabledStatus 根据已选规格与候选值组合查询索引。Path Map 是组合索引，位运算用于生成子集；本次不据此新增算法原创、复杂度评级或性能收益。

当时正文采用：通过位运算枚举有效 SKU 的规格子集，构建组合索引（Path Map），兼容不同来源平台的规格标识；根据用户已选规格禁用无效或无库存选项，并在加购、立即购买前校验所选 SKU、起购量及库存上限。

编写规则同步保留“子集枚举、组合索引、按选择查表”这一层方法说明，算法推导与代码步骤留作面试展开；来源兼容、库存和购买约束保持原有范围，库存缺失时的行为仍见上文。本次仅同步个人文档与技能项目索引，未修改公司代码或新增运行验证结果。

2026-10-22 第四条结算与支付流程复核与编写规则

本人要求继续检查第四条“结算与支付流程”是否合适，补上编写规则并更新上下文，说明为什么保留这些内容。本轮按现有业务案例定位，分别只读核对结算身份与生命周期、公共支付预览和结果流程，以及 PC/H5/RN 端侧接入。现稿已涵盖结算复用、状态隔离、金额依据、提交保护、平台适配与结果处理，适合继续作为一个完整业务案例，不新增全部支付功能或底层工具清单。

首次复核校准了尾句：原“轮询确认结果后更新……”容易让读者以为所有端和渠道都统一走轮询，当前 Web 还存在支付回跳处理路径，因此补入回跳并将“更新”明确为页面数据刷新。随后按本人要求补入同步提交锁，当时版本为：复用购物车与立即购买的结算逻辑，按订单类型和预览编号区分数据，提交成功或取消后只清理对应状态。适配 Web 跳转与 RN WebView 支付，以服务端预览金额为准，重新计价期间禁止提交，通过同步提交锁拦截重复创建支付单；处理支付回跳与结果轮询，确认结果后刷新订单、运单与钱包数据。此版本先由本节末“同日调整提交保护并补全有限轮询”的取舍替代；当前正文以后文“2026-10-29 第三至第五条的技术方法与简述平衡（当前采用）”为准。

首次复核的保留内容与编写理由（历史版本）

规则采用既有“目的、记录、不记录、理由”结构，按以下用途解释取舍：

结算复用与身份隔离： 购物车与立即购买有不同入口，但共用预览、服务选择和提交流程；订单类型与预览编号限定当前状态及缓存的归属，精确清理体现跨页流程的生命周期处理。
金额依据与重新计价： 支付选项变化会改变后端报价，保留服务端预览金额及计价期间禁止提交，说明展示金额与当前提交条件如何衔接，而不是把金额分摊或资金计算归给前端。
支付单创建防重： 用同步提交锁说明异步请求发出前立即占用提交标记、拦截重复调用的处理手段；与第二条针对支持幂等接口的请求 ID 复用各有用途，不扩大为跨端、跨设备或后端的幂等保证。
Web/RN 接入与结果处理： 支付发生在端侧不同容器中，回跳、关闭 WebView 和站内轮询需要衔接结果页面；结果处理后刷新相关查询，说明业务流程怎样收口，不将跳转或关闭本身当作成功证据。

详细路由、支付渠道、轮询次数、接口字段及全部缓存 Key 留作面试展开。本人此前认为支付的主要难度在后端，这一判断继续保留；本条呈现前端实际的状态、交互和跨端接入工作，不包装为后端支付、回调验签或账务系统建设，也不新增性能、转化率或资金安全收益。

只读核对的实现与边界

本轮只读核对的代表入口位于 C:\work\bbdbuy：

结算： packages/business/src/order/submit-order/submit-order-draft.ts 以订单类型和预览编号组成 identity；submit-order-query.ts 与 order-query-keys.ts 按相同范围区分并精确移除预览缓存；submit-order-flow.ts、submit-order-lifecycle.ts 在取得有效业务编号后收口当前流程。旧成功回调只移除自己的预览，是否导航取决于它是否仍对应当前草稿；取消也先核对身份，不清理后来新建的结算状态。草稿保留流程标识及编辑上下文，不扩大为完整商品金额的持久化恢复。
入口复用： packages/business/src/cart/cart-flow.ts 初始化购物车预览，packages/business/src/product/product-detail/product-detail-flow.ts 初始化立即购买预览，两类入口进入同一提交订单 Flow，再按订单类型选择接口；不将复用写成所有参数或接口完全一致。
支付预览： packages/business/src/payment/payment-flow.ts 与 payment-query.ts 用业务单、渠道、优惠和账单地址等参数区分预览；payment-utils.ts 从服务端预览取钱包及外部支付金额。重新获取期间或占位预览不能作为提交依据，选择变化会同步标记旧预览失效，提交时再次检查。
提交保护与创建防重： payment-query.ts 将创建支付单 mutation 的 isPending 暴露为 isCreatingPayment；payment-flow.ts 另有覆盖外层编排的 isSubmitting，三端支付主按钮根据计价、提交状态与提交条件禁用。submittingRef 在等待创建支付单前同步置锁、结束后释放，限定当前 Flow 实例的提交期间，不代表所有结算动作都有同样的同步锁，也不证明后端不会重复建单或扣款。该锁是只读核对时的现有实现；本人随后明确计划移除，尚未在本次任务修改或验证公司代码。
端侧适配： PC 的 apps/pc/hook/business/payment/payment-business.ts 预开窗口并跳转外部支付，原页可进入轮询结果页；H5 对应 adapter 在当前页跳转第三方，钱包支付进入站内结果查询。RN 的 apps/rn/hooks/business/payment/payment-business.ts 与 apps/rn/features/payment/PaymentWebView.tsx 接入外部 HTTPS WebView，关闭或受信站点回跳后进入结果查询，不直接判定成功。
回跳与轮询： packages/business/src/payment/payment-result-flow.ts 的 Web 流程根据模式与渠道分流：站内轮询或钱包走状态查询，其他外部支付可解析回跳并调用后端处理接口。轮询有次数上限，处理中或未知结果达到本地上限时仍属待确认，可主动重新查询；后端明确返回的失败终态另行判断，不将两类“超时”混为一谈。
结果刷新： payment-query.ts 在状态查询得到终态，或支付回跳接口成功后，失效刷新订单管理列表、运单列表与钱包信息查询。正文“刷新数据”指前端查询更新，不表示直接修改后端订单或资金状态，也不扩大为立即刷新所有详情和记录。

同日补充同步提交锁与主动复核要求（历史取舍）

本人在初次复核后追问是否需要点明专用名词，进一步讨论了同步提交锁和 useRef 的关系；随后指出 AI 已写明应主动判断必要技术名，却仍先说合适、等提醒后才建议补充。该反馈针对规则执行与判断方式，不能归结为本人每次追问都改变了表达偏好。本人最终明确要求把同步提交锁补入第四条，并同步编写规则和上下文，后续主动执行复核。

当时将“拦截重复创建支付单”的目标表述具体化为“通过同步提交锁拦截重复创建支付单”。AI 当时认为该补充有源码支撑、能够简短说明方法，应主动提出；后续讨论中进一步校准：实现存在、当前是否必需和是否值得在简历突出，应分别判断，不能仅凭有代码就将细节推荐为要点。useRef 是当时核对到的实现方式，不是同步锁的唯一载体；“有限轮询”当时归为可选范围细化，未追加到正文。以上保留为历史判断，最新采用版本见下文。

复核执行要求已补入本页“编辑标准与复核方式”，并在根 AGENTS.md 的 Resume editing 增加执行入口：主动检查事实、主题覆盖、关键处理方法及表达粒度，给出明确推荐和理由，不能只确认业务覆盖完整就结束审阅，也不机械为每条增加术语。技能项目对照同步第四条当前采用状态。

本轮先新增第四条编写规则、校准结果处理尾句，再补充同步提交锁及复核要求；前三条、其他案例和技能正文不变。源码能够支持当前表达和职责边界，本次未修改或运行公司代码、调用支付或业务接口、执行测试、验证线上结果或新增个人独立贡献结论。

同日调整提交保护并补全有限轮询（2026-10-22 版本，正文已于 2026-10-29 收短）

本人继续询问同步锁与 useRef 的必要性，并指出创建支付单已有 TanStack Query mutation 的 isPending，正常按钮点击由提交状态与禁用控制。本人认为当前没有需要额外防范的重复调用场景，明确打算后续移除代码中的 submittingRef，要求按这一取舍重新审视简历。该移除是本人已表达的后续计划，不是本次已经完成或验证的代码修改，也不表示移除所有 ref 或所有前端提交保护。

本轮不再将同步提交锁列为第四条要点，改为“在重新计价或提交期间禁用支付按钮”。该限制在只读核对到的三端页面已经存在，不依赖计划中的移除才成立；不将按钮禁用扩大为任意程序调用的互斥保证。创建接口的 isPending 与外层 isSubmitting 覆盖范围有大量重叠，但后者还包含准备窗口和创建后处理；是否合并属于后续代码调整，正文不写字段名，也不把额外状态说成防重必需。

此前已讨论轮询次数上限与待确认结果，但先前将“有限轮询”归为可选，后续建议稿又只替换同步锁措辞，未带入这部分说明。本人指出遗漏并要求重新改稿、主动按规则复核。本轮在正文保留“有限轮询”，同时写清达到上限仍未确认时支持主动重新查询；重新查询针对支付状态，不是重新发起支付或扣款，本地达到查询上限不能直接判定支付失败。

当时详述正文为：复用购物车与立即购买的结算逻辑，按订单类型和预览编号隔离结算状态与查询缓存，提交成功或取消后只清理对应数据。适配 Web 跳转与 RN WebView 支付，以当前有效的服务端预览金额为准，在重新计价或提交期间禁用支付按钮；处理支付回跳与有限轮询，轮询达上限仍未确认时支持主动重新查询，确认结果后刷新订单、运单与钱包数据。

本轮主动按既有规则复核后的取舍如下，不能仅以“事实没有错”代替对完整性与代表性的判断：

结算状态与缓存： 将原“区分数据”明确为按订单类型和预览编号隔离结算状态与查询缓存，让隔离对象清楚；成功或取消时仍只清理对应数据。旧回调不影响新草稿的详细身份检查已被该表述概括，不必另加一套术语，也不扩大到所有支付异步回调。
有效预览与提交限制： 明确使用“当前有效的服务端预览”，对应源码排除正在获取、占位及选择不匹配的预览，避免只交代金额来自后端却没有说明旧报价能否提交。支付渠道、优惠和地址等完整预览参数、失效标记与 Query Key 留在实现说明，不展开全部选择规则。
平台接入与结果确认： Web 跳转、RN WebView、回跳与有限轮询共同覆盖接入及结果处理；轮询收到成功或失败终态时停止，未确认达到上限时可主动重查。关闭 WebView 或回跳本身不是支付成功证据，具体次数、间隔、窗口策略和渠道分支无需放入正文。
刷新范围与职责边界： 继续保留订单、运单与钱包数据刷新；对应的是相关查询失效和重取，不扩大为前端变更后端资金、回调验签或账务处理。第二条的可恢复请求重试与本条的支付结果轮询、主动重查各有职责，不重复完整请求策略或新增幂等承诺。

据此，当前条目已覆盖结算复用与清理、有效报价与提交限制、跨端接入、结果确认与上限后处理及数据刷新，未发现必须继续补入正文的代表性环节。编写规则和技能项目对照同步当前取舍，历史同步锁版本保留为历史，不再作为下一轮改稿起点。本轮仅修改个人资料文档，没有修改或运行公司代码、调用业务接口、验证支付结果或新增个人独立贡献及线上收益。

2026-10-22 第五条复核：三端客服聊天

本人要求继续审阅第五条，按既有规则主动检查遗漏，补充编写规则和上下文，并说明为什么保留这些内容。本轮先读项目规则、历史聊天素材与技能索引，再只读核对公共聊天 Flow、消息类型和 Query，以及 PC/H5/RN 的连接、图片与页面接入；未修改公司代码、运行测试或调用接口。

原文为：抽取三端共用聊天逻辑，接入 WebSocket 与图片上传，支持本地消息回显、回包去重及断线重连；确认（ACK）超时后标记失败并支持重发，切换会话时取消旧查询、核对返回会话，避免消息混入。既有素材来自 2026-09 简历，2026-10-13 恢复为主项目案例，2026-10-19 根据代码补充历史取消与会话边界；本次继续核实实现和表达，不由源码存在新增个人独立设计、真实线上事故或测试通过结论。

初次按现有实现整理的表达与编写理由（历史版本）

当时正文为：抽取三端共用聊天逻辑，接入 WebSocket 与图片上传；以临时消息 ID 关联服务端回包、替换本地回显，并按服务端消息 ID 去重。发送确认（ACK）超时后在本地标记失败并支持重发，断线后有限自动重连并支持手动重连；按业务编号过滤实时消息，切换会话时取消旧历史请求，核对请求序号与会话标识，避免旧结果混入。该版本保留为源码对应的历史表达；当前简历版本见“2026-10-29 第三至第五条的技术方法与简述平衡（当前采用）”，本节末保留新方案详述与实施边界。

本轮按事实、主题覆盖、关键方法和表达粒度作出以下判断，并同步“目的、记录、不记录、理由”规则：

保留共用流程与端侧接入。 第一条概括架构，第五条以实际消息流程支撑复用。公共 Flow 管理消息、历史、连接与重发，三端分别提供 WebSocket、图片上传和本地预览能力；不必再复述完整 Monorepo 或全部分层名，也不能将公共代码写成三端共享同一个运行中的连接。
补明回显与去重的方法。 原稿只列本地回显、回包去重，缺少两者怎样对应的说明。临时消息 ID 用于将服务端回包关联到本地气泡并替换回显，服务端消息 ID 用于避免列表重复，两种标识承担不同职责，值得简短写入。正文不用再叠加“乐观更新”“状态机”等名称，具体字段与步骤留作面试展开。
保留确认超时与重发，明确失败发生在本地。 ACK 在这里是带临时标识的服务端回包确认，不是客服已读。超时表示客户端未在期限内收到确认，源码会把本地消息置为失败态；不能由此断言服务端未收到，也不能因为重发复用标识就推定后端幂等。
说明连接恢复的边界和出口。 当前是固定间隔的有限自动重连，连续失败达到上限后停止，并有手动重连入口；成功建连会重置尝试计数。补明有限与手动入口即可，不列具体参数，也不将其改写成指数退避、心跳保活或离线补偿。
校准会话隔离表述。 原“核对返回会话”容易被理解为逐条验证历史响应体中的会话字段。实际是实时消息按业务编号过滤；历史请求取消之外，还比较请求序号、发起时捕获的业务编号与当前会话是否一致，过期结果不写入列表。正文改为“取消旧历史请求，核对请求序号与会话标识”，分别交代处理对象和校验手段，不能把历史请求误写成 TanStack Query 管理的查询。

只读核对入口与事实边界

代表入口位于 C:\work\bbdbuy，行号为本轮只读核对时的定位，后续代码变化需重新搜索：

共享合同与三端接入： packages/business/src/chat/chat-types.ts:43 定义实时连接回调和最小连接合同，:62 定义图片上传、预览及释放能力；apps/pc/hook/business/chat/chat-business.ts:87、apps/m/hook/business/chat/chat-business.ts:89、apps/rn/hooks/business/chat/chat-business.ts:81 注入同一公共 Flow。Web 使用 File、FormData 与 Object URL，RN 使用文件描述对象及本地 URI；这些是适配细节，不单列正文亮点。
临时标识、回包与列表去重： chat-flow.ts:574 创建本地消息 ID 并先插入发送中气泡，:534 将该 ID 作为 tempId 发出；:220 清除对应确认计时，:244 用回包 tempId 移除临时气泡，同时去除已有同服务端 id 的条目，再加入回包消息。去重依赖回传标识，不证明后端去重、跨设备去重或端到端仅处理一次。
确认及失败恢复： chat-flow.ts:172 为成功交给连接发送的消息安排确认超时，:158 更新本地失败状态，:554 在连接不能发送时也标记失败，:306 断线时将仍在发送的消息标为失败。:683 重发沿用原消息 ID 和业务编号；图片上传失败可重试上传，已有上传地址的消息重发可复用地址。当前没有证据支持“确认超时一定未送达”“自动补发全部失败消息”或服务端幂等。
重连与生命周期： chat-flow.ts:258 以聊天活跃和用户信息为建连前提，:278 安排固定延时重连并限制连续自动重连次数，:299 成功后重置计数，:351 提供主动重连。默认重连间隔为 3 秒、连续自动重连上限为 5 次、确认超时为 15 秒，仅作为代码参数记录。停用或卸载时关闭连接、清除连接定时器，卸载时还会清确认计时；PC 随弹窗开关、H5 随页面挂载、RN 随路由聚焦控制活跃。未见聊天专用 AppState 前后台处理、网络恢复监听、心跳或专用 Token 认证帧，不能把它写成始终在线的全站单例连接。
历史请求与实时会话隔离： chat-flow.ts:411 手动请求历史分页，使用 AbortController，并捕获发起时业务编号；:441 比较请求序号和当前业务编号，:494 在切换时取消旧请求、递增序号并重置列表。实时消息另在 :224 按业务编号过滤。这里没有逐条校验历史响应记录会话字段的保证，也没有取消全部上传、上下文操作或已发送消息；请求序号检查用于拦截即便取消未及时生效仍然返回的过期结果。
业务会话与辅助能力： chat-draft.ts 组织普通、订单与运单咨询的业务上下文；chat-flow.ts:358 清理旧业务上下文并建立新上下文，切换业务编号不等于每次重建 Socket 或切换 Socket 频道。历史分页按消息 ID 去重追加，图片先本地预览再上传，未读数刷新及业务卡片等能力也有实现，但本条优先消息身份、失败恢复与会话隔离，其他功能留作面试材料，不扩成聊天功能清单或完整 IM 系统。

按当前条目范围，已覆盖三端复用与图片接入、本地回显与回包合并、确认及重发、连接恢复和实时/历史会话隔离，未发现必须继续补入正文的代表性环节。与第二条的通用请求管理有区别：聊天历史请求由 Flow 手动控制取消和时序，不能因为项目使用 Query 就将全部聊天状态归给它。后台的“客服通信”仍聚焦组件、订阅和连接使用，两处不合并也不完整重复。

技能项目对照同步第五条的当前采用状态；本轮不新增消息必达、已读回执、离线消息补偿、严格有序、完整自动化覆盖、线上收益或个人独立主导结论。前四条及其他案例正文保持本轮开始时的版本。

同日补充：聊天可靠性问题与后续优化（未实施）

本人在回顾整个聊天实现后，认为方案还不够成熟，要求评估优化方向；随后明确要求先把问题和方向记录到上下文，代码留待后续有时间再优化，并询问能否先把简历按新方案写得更好看。本轮记录现存实现、源码可构造的风险、待确认合同及候选表达，不新增开发日期、排期、已修复或已验证结果。此前“未发现必须继续补入正文的代表性环节”针对简历案例覆盖，不是聊天可靠性验收；下面的继续审计发现了需要处理的具体时序问题。

优先处理的问题与优化方向

历史快照覆盖并行到达的消息或本地失败气泡。 chat-flow.ts:460-461 在首次加载或刷新第一页后直接 setMessages(nextMessages)，而实时回包独立更新列表。可达路径为：打开聊天、历史请求较慢；用户发送消息但连接尚未就绪，本地出现失败气泡，页面因 sendMessage() 返回 true 清空输入；历史随后返回，失败气泡与重试入口被整体替换。请求期间收到的新实时消息也存在被覆盖的窗口，撤回通知触发第一页刷新时同样使用该路径。建议统一历史、实时和本地待确认/失败消息的归并规则，保留仍需处理的本地记录，并按客户端及服务端标识核对。撤回、删除等更新还需保持其明确语义，不能简单把所有旧条目永久追加保留。这是前端列表与交互的风险，不等于后端已保存的消息被删除，也不是已经复现的线上事故。
会话过滤之前的副作用，以及图片上传后的迟到发送。 chat-flow.ts:213-215 先从 SERVER 消息更新 receiverId，:224 才按业务编号过滤；切到 B 后，如果先收到 A 的消息，A 的接收方字段可能写入当前上下文。另在 :610-631，图片上传完成后仍以发起时捕获的业务编号发送，但 :550-551 会读取当前接收方；切换会话期间可能出现旧业务编号与新接收方混用。建议先检查消息归属再更新会话元数据，将发送目标、图片任务及回调绑定到发起会话，必要时检查任务或连接所属代次。离开会话后继续发送还是取消，是待明确的交互约定，不自动替本人决定。前端晚到发送路径存在；是否因此后端错投，需要确认后端如何解释业务编号与 receiverId，不能先记成已发生串会话事故。
连接恢复后没有客户端消息补拉。 chat-flow.ts:299-304 的 onOpen 只更新连接状态和重置重连次数，没有补拉历史或核对断线窗口。若服务端不重放消息，断线期间的消息可能无法在当前列表及时出现；服务端是否自动补推尚未确认。建议建立“连接恢复 → 补拉服务端记录 → 与现有消息归并核对”的流程，并考虑返回前台或网络恢复后的同类同步。前期可利用已有历史接口，较完整的方案需按每个会话的游标或最后消息身份继续补拉；不能把只请求最新一页视为任意断线时长都已补齐。RN 已有全局 AppState/NetInfo 同步，但 apps/rn/hooks/common/use-app-network-sync.ts:36 主要处理 TanStack Query，聊天历史由 Flow 手动请求，不能据此前者认定聊天恢复已经覆盖，也不能笼统说整个 App 没有前后台处理。
确认、重发与历史核对缺少已明确的后端合同。 当前重发复用临时消息 ID，但前端回包去重主要依赖服务端消息 ID；若同一临时 ID 的两次处理返回不同服务端 ID，迟到回包可能保留为两条。若后端返回同一服务端记录，现有去重可以收敛，因此不能在未读后端时断言后端没有幂等。ChatHistoryRecord 类型声明了可选 tempId，但 normalizeHistoryMessage 未保留它，历史消息与本地待确认消息还缺少统一的关联核对。后续应确认稳定客户端消息标识的范围、ACK 是否代表已保存、同标识重发是否返回原记录，以及历史与补拉是否回传可关联标识；配合后端去重约定处理重复写入。第二条针对支持幂等写入接口的表达，不构成聊天 WebSocket 协议已有幂等的证据。

上述四项来自静态代码时序分析，尚未运行复现；其中前端覆盖、过滤顺序和迟到回调的路径可由源码定位，实际错投、断线消息重放和后端重复处理取决于尚未确认的合同。建议先修消息归并与会话上下文，再完成恢复后的补拉核对，并与后端明确确认及重发语义；代码和协议可按依赖并行准备，顺序不是本人确认的排期。

后续可再完善重连退避与随机抖动、网络及前台恢复联动、消息/会话标识关联日志，以及少量针对具体时序的验证：慢历史返回前已有新消息或失败气泡、确认超时后的迟到回包与重发、断线窗口超过一页、图片上传期间切换会话。已有的草稿和工具函数测试不等于覆盖这些流程，本轮未执行或新增测试。

新方案候选稿与最初使用取舍（历史记录）

当时 AI 建议先打磨新方案，作为后续实现和面试准备的目标，与可投递的已实现经历分开；因此最初仅将下文保存为待实现候选，未替换正文。本人随后明确要求按“新方案已实现”的前提改写第五条，该最新指令已在下文执行。此处保留此前写作取舍，不将本人提出“先写好看、代码以后再做”记录为新功能已经完成的事实。

当时保存的待实现候选稿：新增归并、任务隔离、恢复补拉及后端幂等配合尚未完成或验证；这是文案来源记录，不是实现证明。

三端客服聊天 · 待实现候选稿： 抽取三端共用聊天流程，接入 WebSocket 与图片上传；统一归并历史消息、实时回包与本地待确认消息，通过客户端消息标识关联回包，并按服务端消息 ID 去重。将发送目标与图片任务绑定到发起会话，支持有限自动重连、手动重连及恢复后的消息补拉与核对；结合发送确认（ACK）和后端幂等约定处理超时重发。

该稿中的公共 Flow、图片接入、临时标识与回包关联、确认计时及有限/手动重连已有实现；统一归并、完整的任务与发送目标绑定、恢复补拉及明确的后端幂等配合属于待完善内容。后续应按实际落地、联调和验证范围逐项采用，并继续区分客户端显示去重与后端重复处理、连接重建与消息恢复、确认超时与服务端未收到。候选稿不预先承诺消息必达、全部断线消息补齐、严格有序或已读能力。

当时只更新了修改上下文和技能项目对照，没有替换正文；该取舍随后由本人明确的新指令调整，当前简历与实际进度见下文。以上记录阶段没有修改公司代码、连接服务、调用聊天接口、实施部署或验证上述优化。

同日按本人要求采用新方案完成式表达（当时版本，2026-10-29 已收短）

本人随后明确要求：“把第五条‘三端客服聊天’按新方案已实现来写，编写规则和上下文也一起更新，代码还没优化的实际情况在上下文里记清楚。”本轮据此将新方案作为第五条的完成式文案写入求职简历，并同步编写规则和技能索引。这是本人指定的表达前提，不是本人确认代码已经完成、后端已经联调或新方案已经验证；此前只保留候选、不替换正文的做法不再作为当前写作约定。

当时详述正文为：抽取三端共用聊天流程，接入 WebSocket 与图片上传；按会话统一归并历史、实时及本地待确认与失败消息，通过客户端消息 ID 关联回包、替换本地回显，并按服务端消息 ID 去重。发送确认（ACK）超时后支持复用原客户端消息 ID 重发，配合后端幂等约定处理；将发送目标与图片任务绑定到发起会话，切换时取消旧历史请求并校验请求序号与会话标识；支持有限自动重连、手动重连及恢复后的消息补拉与核对。

当时编写规则按以下职责解释详述版本，既保留原有方法，也覆盖本人指定的新方案：

共享流程与消息归并： 三端共用流程承接第一条的业务复用，WebSocket 和图片上传说明接入范围；归并历史、实时及本地待确认与失败消息说明目标方案如何衔接多来源状态，明确保留失败气泡与重试机会，避免只罗列聊天功能。
标识、确认与重发： 客户端消息 ID 关联服务端回包并替换本地回显，服务端消息 ID 用于列表去重；重发复用原客户端消息 ID，说明后端怎样按约定识别同次消息操作。ACK 与后端幂等约定交代前后端配合，不扩大为本人负责后端存储或端到端仅处理一次。
会话与任务归属： 发送目标和图片任务绑定发起会话，说明迟到上传及回调的目标归属；旧历史请求取消、请求序号与会话标识校验继续保留，不能因新方案侧重任务绑定就遗漏原有的历史时序处理。
连接及消息恢复： 有限自动重连、手动重连和恢复后的补拉核对分别说明连接恢复方式与数据同步，具体次数、间隔、游标和接口细节仍留在上下文，不预先承诺任意断线时长都已完整恢复。

实际实施状态仍未改变： 统一归并以保留本地待确认/失败消息、发送目标与图片任务的完整会话绑定、连接恢复后的补拉核对，均尚未按新方案改造或验证；ACK 是否代表持久化、稳定客户端标识的范围、同标识重发是否返回原记录、补拉是否回传关联标识等后端约定仍待确认。原有公共 Flow、图片接入、临时标识回包关联、确认计时、有限/手动重连和历史请求取消及时序校验有代码依据，但不能据此认定新增部分已落地。

上文四项可靠性问题、源码入口、优化顺序与待确认事项完整保留，不因文案改用完成式标为已修复。后续讨论、面试准备或代码实施时，先区分当前简历的指定表达与实际进度，再按真实改造和验证结果更新记录；不将该版本自动当作个人新熟练度、独立主导、测试通过、线上效果或业务收益的证据。本轮只修改三份个人资料文档，没有修改或运行公司代码、联调后端、调用业务接口或部署。

2026-10-22 第六条复核：RN 兼容与稳定性

本人要求继续复核第六条，按现有规则主动检查遗漏，并同步编写规则、上下文和取舍理由。本轮只读核对 RN 组件、当前构建配置和排障文档，保留交互适配、Hermes 启动排查及 Android 标签页改造的范围；补回原文概括后不够明确的底栏测量、父子横滑协调方法，不扩成全部移动端问题清单。

当时正文与编写取舍（2026-10-29 已微调）

RN 兼容与稳定性： 适配 iOS / Android 安全区与键盘遮挡，测量底栏高度调整输入滚动偏移，并使底栏随键盘移动；子横滑期间暂停父级横滑识别，结束或取消时恢复。根据启动日志排查 Hermes 兼容问题，对齐双端运行时与编译配置；针对 Android 标签页崩溃，移除原生分页器，改为仅渲染当前内容并通过手势切换。

本轮判断及理由：

保留安全区与键盘，补清测量方法。 本人此前确认双端适配复杂，现有代码根据安全区留白，并可关闭外层已处理过的安全区；键盘模式通过实际底栏高度计算输入滚动偏移，底栏另随键盘移动。比只写“联动底栏与输入滚动”更能说明处理方式，无需把页面、组件和参数逐一写入正文。
保留嵌套横滑，补清父子协调。 子区域触摸期间占用横滑，父级不抢手势；交互结束或取消时恢复。多触点集合、嵌套计数、向上层传播和卸载释放是实现细节，留在下文，正文不另造复杂算法名称。
保留 Hermes，校准根因和方法的表达。 旧句“排查 Hermes 与编译链不匹配的启动问题”容易被读成已经独立确诊唯一根因；当前依据为升级文档中的日志分析及现有配置，不是本轮重新分析原始崩溃文件或实机验证。改为排查兼容问题、对齐双端运行时与编译配置，明确做了什么，不写已彻底解决启动崩溃。
保留 Android 标签页改造，说明替代结构。 只渲染当前内容与普通手势切换已有实现，补出移除原生分页器，让读者理解改造前后。ViewPager2 / RecyclerView 是文档指向的高概率回收路径，尚非唯一确诊根因，具体原生类名继续留作面试入口；不新增“修复原生底层缺陷”或线上稳定性收益。

当前实现与只读来源

以下为本轮本地源码定位，行号会随后续代码变化；历史提交 012d272a、aae2bb65 的演进线索继续沿用 2026-10-19 历史素材索引，不把旧版本依赖和文档当成当前配置。

范围	实现与核对入口
安全区及页面接入	SafeBottomActionBar 按底部 inset 与最小间距留白，允许外层已消费安全区时关闭重复处理；退款页实际启用键盘适配。
底栏测量及键盘联动	OverlayFlatList 通过 onLayout 测量底栏，传给 KeyboardAwareScrollView 的 bottomOffset；同文件第 333 行由 KeyboardStickyView 移动底栏。键盘模式按页面启用，不能写成全部列表或聊天已统一使用这套容器。
嵌套横滑	SegmentedTabs 触摸管理记录触点，全部结束、取消及卸载时释放；第 121 行起按嵌套计数向父级传递占用，第 149 行占用期间不取得父级横滑响应。另有全屏子交互打开时的占用入口，不能把处理范围只理解为单层 Tab。
Hermes 启动及配置	升级文档记录启动链兼容线索及 iOS TestFlight 的 SIGABRT；app.json 双端关闭 Hermes V1、从源码构建 RN/Hermes，Babel 配置使用 hermes-v0，工作区锁定 hermes-compiler 0.15.0。上述为当前对齐方法，不代表永久使用旧引擎是通用最优选型。
标签页渲染与手势	SegmentedTabs 使用 PanResponder 判断横滑方向、距离与速度，第 223 行起仅渲染 activeTab；Android 问题记录说明原生分页回收路径的证据及不确定性，第 373 行保留 Release 与灰度验证要求。

验证及范围边界

升级记录的验证节已有 Android 开发壳运行及标签页人工流畅度反馈，但最终锁文件与配置下的构建、Android Release 冒烟、全部 Tab 回归、iOS Dev/Release 和 Play 灰度仍有待办。本轮未运行公司项目、设备验证或构建，也未重新取得原始崩溃日志；不能由配置与源码存在，新增双端 Release 已通过、线上崩溃消除、全设备兼容或性能数字。Hermes 运行时配置变更需要重新构建原生壳，不能记成 OTA 已修复。

Android 分页回收、ReactViewGroup 绘制顺序和键盘 Insets 动画竞态是不同问题，不能合并为本条已全部解决。react-native-screens / gesture-handler 的最终依赖演进继续按 2026-10-19 的纠偏记录及最终 package/lock 判断；旧补丁叙述不恢复为当前成果，Keyboard Controller / Reanimated 的升级规划不转为已完成。

本条按现有实现及排障记录撰写，不沿用第五条针对新方案的假设完成式前提。源码定位不增加个人独立主导或逐项熟练度；本人承担环节和验证范围仍按原有个人陈述及后续确认维护。此次只调整第六条、补充四项编写规则和对应索引，前五条及后两条正文保留，未新增公司代码改动、部署或日程安排。

2026-10-22 第七条复核：线上问题排查

本人要求继续检查第七条，主动判断遗漏，并同步编写规则和上下文。本轮按事实、主题覆盖、关键方法及表达粒度复核，结论为保留原正文，新增“目的、记录、不记录、理由”四项规则；不是每轮复核都要扩写技术词或替换已准确的表达。

线上问题排查： 通过埋点定位 Chrome 自动翻译改写 DOM 导致 React 重渲染崩溃的问题，在 PC/H5 禁用页面自动翻译，保留站内多语言切换。

为什么保留这些内容

真实故障与定位手段。 本人已于 2026-10-19 确认真实线上发生过该问题，并通过增加埋点才定位到原因；该事实继续有效，不因当前代码中的日志范围变化重新降为假设。此处说明具体排障经历，不扩大为完整监控平台建设。
触发原因。 Chrome 自动翻译改写页面 DOM，后续 React 更新找不到原有节点，是本人已说明的故障机制。现稿已说明问题为何发生，不需要再补 React 内部协调过程；没有当时原始堆栈，不新增 NotFoundError、DOMException、removeChild / insertBefore 等精确异常或调用，也不把它改成 SSR / hydration 问题。
处理范围与方法。 PC/H5 根布局的禁翻译声明有当前源码支持，正文“禁用页面自动翻译”已经说明处理办法；notranslate、translate=“no” 及 google 元信息留在下文即可，不为增加技术词继续展开。此处指页面声明不参与浏览器自动翻译，不保证所有浏览器和第三方插件都遵守。
多语言取舍。 海外用户仍可通过站内多语言切换选择语言，说明限制浏览器翻译后的产品使用方式。该点值得保留，但不由“保留入口”推定全部语言、设备或回归测试通过。

本条作为 Web 端真实线上故障案例独立保留，与第六条 RN 交互及原生兼容排查各有侧重。现稿已经交代定位、原因与处理，没有需要硬补的关键技术方法；将“埋点”细化为“错误日志埋点”只是可选措辞，本轮不据此改写正文，也不补造当时使用的具体采集字段、复现步骤、故障率和验证结果。

来源及当前代码边界

范围	依据与边界
个人确认的历史经历	本页 2026-10-19“浏览器自动翻译引发的真实故障”保存本人关于线上问题、增加埋点定位、禁止自动翻译及 React 更新找不到原节点的陈述；本轮没有新增或重新取得当时原始故障日志。
PC/H5 翻译声明	PC 根布局与 H5 根布局均配置 google:notranslate，根 HTML 有 notranslate 类及 translate=“no”；这是页面翻译声明，不是强制拦截所有翻译工具的能力。
站内语言入口	PC 语言币种选择器与 H5 语言设置页继续提供站内切换，未因根布局禁翻译而移除。
当前错误采集	PC error.tsx 和 H5 error.tsx 仅在 development 上报 source、name、digest、pathname；对应 PC Route Handler 与 H5 Route Handler 在非开发环境返回 404，开发环境向服务端控制台输出白名单字段。不能写成当前线上已采集完整堆栈、浏览器信息和组件栈。
历史实现与后续规划	只读历史中的 `bc9d7c85` PC、`a7270987` H5 错误页存在较早的 message、cause、stack、路由及 UA 等采集，支持“历史有采集实现”，不证明这些字段就是本人当时的根因分析依据。错误反馈文档仍将 Sentry SDK、采样与 Issue 聚合列为后续；不由文档存在推定已接入。

本轮只读核对公司源码和本地历史，未运行项目、复现浏览器故障、调用日志接口或执行设备/页面回归；只在个人站点补充第七条规则、复核上下文和技能关联，简历全部条目正文保持本轮开始时的内容。不新增个人独立主导、监控平台、量化收益、投递或日程结论。

2026-10-22 第八条复核：测试与构建发布（阶段版本，来源与边界保留）

本人要求继续按规则主动检查第八条，补充编写规则、上下文和保留理由。本轮分别只读核对单测及 Playwright、Web 构建部署脚本与云效接线文档、RN EAS 配置和发布文档。原文的测试、Web 交付、PM2 排障及 RN 发布范围可保留，没有发现必须删除的事实；本次补清代表性测试规则、Web 版本切换方法，以及 OTA 与原生包更新的分工，不恢复全部命令和配置清单。

本节保留当时的正文、源码核对和事实边界；最新采用表达见“2026-10-31 第八条结构调整与 PM2 处理方法”。

当时正文与取舍理由

测试与构建发布： 为请求取消、会话清理和结算状态隔离等规则配套单元测试，补充 PC/H5 Playwright 端到端用例；建设云效 CI/CD 与 RN EAS 构建发布流程。Web 按版本目录部署 standalone 制品，通过软链接切换版本，配套健康检查和失败回退，处理测试环境 PM2 旧入口导致运行旧代码的问题；承担 Android / iOS 提审发布，按运行时兼容范围与发布通道管理 OTA，涉及原生变更时升级版本并重新构建安装包。

测试不只列名称，也说明验证对象。 原文概括请求、认证和交易，本次改用取消、会话清理与结算状态隔离作为代表规则，说明前面设计的边界有对应断言；Playwright 保留为浏览器流程验证入口。具体测试工具、Mock 方法与更多条件留在下文，不展开成测试功能清单，也不把已有测试扩大到全部 SKU、聊天新方案或后端付款链路。
Web 发布补出关键切换方法。 “按版本发布”原本成立，但没有显露版本目录与软链接如何支撑切换和回退；本次补入这一简短方法，保留 standalone、健康检查与失败回退。相比单加更多平台名，这项补充更能说明处理方式；它是表达上的补强，不表示旧文事实错误，也不因此改称蓝绿或零停机发布。
PM2 案例继续保留。 该例说明制品和 current 已更新，运行进程仍可能沿用旧入口；处理包含核对版本、静态资源及进程 script/cwd，识别旧入口后重建进程定义。正文保留问题及 dev 范围，详细诊断和首次接管回退放在来源中，不将它与第七条的生产浏览器故障混为同一案例。
RN 交付说明工具与更新边界。 EAS 构建和双端提审沿用已有经历；“OTA 兼容版本、通道管理”改为按运行时兼容范围与发布通道管理更新，并说明原生变更需要升级版本及重建。正文用中文说明方法即可，Runtime Version、Profile 和 Channel 的具体值留作面试入口，不恢复一串配置名。

测试实现与覆盖边界

当前 request/business 测试脚本使用 Node 内置 node:test；不能因存在空的 vitest.config.ts 就写成使用 Vitest。部分业务测试通过 Testing Library / jsdom 挂载 Hook 和 QueryClient，替换网络及端侧依赖，不等于验证真实后端行为。代表入口：

范围	只读依据与边界
规则单测	请求测试脚本、业务测试脚本；取消信号、退出及换号清理、结算生命周期有对应断言，涵盖取消传播、旧账号状态清理及迟到完成不清理新草稿等条件。
Playwright 流程	配置包含 PC/H5 Chromium 项目，H5 的移动设备模拟不等于真机或 Safari 验证；H5 结算用例使用 Mock，PC 结算用例需开发环境凭据与显式开关，终点为支付预览，不执行最终付款。真实认证、购物车另有串行 dev 配置；不能把 Mock 与真实环境用例都写成默认完整执行。
云效及构建入口	开发部署说明、生产部署说明记录云效接线；开发构建脚本及生产对应入口执行公共包构建、App 类型检查和 Next standalone 构建，未在这些入口中发现调用单测或 Playwright。源码支持构建发布流程，不支持新增“所有自动化测试通过后才允许发布”的门禁结论；本轮没有查看远端流水线实际配置。

测试存在、本人原有测试实践、个人独立编写范围和测试实际执行结果继续分开记录。本轮未运行公司项目或测试，不新增通过率、覆盖率、独立编写全部测试或第六条 RN Release 验证完成的结论；也不因 Playwright 配置中有 CI 分支就认定云效已经执行它。

Web 与 RN 发布方法及来源

范围	只读依据与边界
Web 版本切换与回退	部署脚本每次建立独立 release 目录并写版本标识，软链接切换替换 current；回退区分已有 release 的切回重载与首次接管旧入口时恢复旧 PM2 配置。启动、健康检查和状态保存失败会尝试回退，回退本身仍可能失败并需人工检查，不写必然自动恢复。
健康检查与 PM2 案例	健康检查以 HTTP 可访问性为依据，没有核对发布 ID 或完整业务流程；开发环境案例记录旧 PM2 入口、版本及静态 chunk 核对，不能只凭 health 成功认定新版本业务已验收，也不改成生产事故或零停机成果。
RN 构建、环境与身份	eas.json 区分 Dev Client、Android Preview、生产 APK 和商店包；环境说明及 app.config.js 分别处理 API/H5 环境和 App 原生身份，通道不能代替后端环境、包名或原生能力配置。配置值和构建命令不全部放入正文。
OTA 兼容范围	app.json 当前 runtimeVersion 使用 appVersion 策略，不是 Fingerprint 自动检测；OTA 规则限定兼容运行时内的 JS、样式和资源。原生依赖、权限、Plugin、Hermes 等变更需升级 App version 并重新构建，不能将 OTA 作为原生升级手段或凭文案保证兼容自动判定。
商店提审与通道	iOS 发布说明中 auto-submit 上传 App Store Connect/TestFlight，不自动提交 App Review；验证后仍需人工审核提交及公开发布操作。TestFlight 与 App Store 共用 production 构建身份和通道，不能写成两套独立 OTA 灰度环境；staging/production 配置存在不等于灰度治理或全部商店审核已通过。

生产 Tag 准入与制品环境校验、商店强制升级优先于 OTA 的协调可继续作为面试素材，按当前代表性取舍不全部加入正文。RN 发布完善记录仍列有 OTA 灰度、回滚演练等待办，既有发布经历不因此被否定，这些待办也不由文案改写变成已完成；第六条保留的原生改造 Release / 灰度验证边界继续有效。

本轮仅修改个人站点第八条、四项编写规则及相关索引，其他条目正文保留；没有修改或运行公司代码、调用 EAS、提交商店审核、触发流水线、执行部署或远端操作。各配置和手册仅支持已定位实现，不新增个人独立主导、线上验收、量化收益或日程安排。

2026-10-23 SKU 规格联动移除来源兼容表述

本人回顾规格标识兼容后指出：“后端给的数据好像都是统一的 propId”，认为这可能是多余处理、不必单独作为简历亮点，随后明确要求删除“兼容不同来源平台的规格标识”，并同步编写规则和上下文。本轮按该要求移除正文半句，删除规则中对来源兼容的记录与保留理由，补充“不因代码存在兼容分支就推定真实多平台适配经历”的边界；技能项目对照同步当前采用状态。

本人的“好像统一”保留为待核实回忆，本轮没有核验后端接口合同或全部来源的真实响应，不能写成已经确认所有接口统一使用 propId。已读源码中的属性 ID 字段兼容、属性值对与单独值 ID 两套索引仍是实现事实，但不足以证明实际业务需要这些分支；此前据此解释为真实多来源适配需求的判断收回，不再作为本条的采用理由。

删除来源兼容后的正文为（同日补充选购联动之前的版本）：

SKU 规格联动： 通过位运算枚举有效 SKU 的规格子集，构建组合索引（Path Map）；根据用户已选规格禁用无效或无库存选项，并在加购、立即购买前校验所选 SKU、起购量及库存上限。

本条继续突出组合索引、选择联动与购买前约束，位运算方法及库存缺失时的既有边界保持不变。2026-10-22 的来源适配解释与旧正文保留为历史，不再覆盖本次最新取舍。此次是对经历依据的校准，不是对其余案例进行篇幅压缩；本人此前说明先保留完整版本、继续优化后面的内容，该偏好继续适用。

本轮只修改三份个人资料文档，没有删除或调整公司代码中的兼容分支，也没有运行公司项目、调用接口或新增验证结论。代码是否清理，需根据实际接口约定另行判断，不由简历删除推定代码已改。

同日补充规格选择与选购联动（当前采用）

本人随后询问商品详情与 SKU 是否还有值得写的亮点，认为当前一句没有充分显示工作内容。重新只读核对公共详情 Flow、SKU 计算、展示模型及 PC/H5/RN 接入后，建议优先补入规格变化后的图片、SKU 价格和数量联动，尤其是切换 SKU 后对已有数量的自动校正；本地选项状态与接口缓存分离、局部刷新处理保留为面试素材。本人明确认可这版正文并要求同步规则和上下文，本轮据此更新第三条，不恢复已删除的来源兼容表达。

当前正文为：

SKU 规格联动： 通过位运算枚举有效 SKU 的规格子集，构建组合索引（Path Map），支持任意顺序选择与反选，动态禁用无效或无库存选项；联动规格图片、SKU 价格和数量范围，切换 SKU 后按起购量与可用库存调整购买数量，并在加购、立即购买前校验完整规格及数量条件。

本次补充的用途与依据：

任意顺序选择与反选： 组合 key 排序后查表，选择动作不要求先选某个规格组；再次点击已选项可取消，再按当前组合更新候选禁用状态。组合键及子集生成、候选判断、反选是具体入口。正文用这些行为说明组合索引怎样服务交互，不新增算法原创或性能收益。
图片与价格联动： 规格选择更新规格图及选项状态；当前 SKU 派生与价格展示使用已选 SKU 数据。商品级有效折扣价可能优先展示，不能写成全部展示价格只由 SKU 决定，也不是每次选择都向后端实时计价。PC 会联动主图库，H5/RN 主要在规格弹层展示相应图片，正文统一称“规格图片”，不宣称三端完全相同的主图行为。
数量范围与购买条件： 数量派生与校正根据当前 SKU 计算上下限，第 180 行起在边界变化时调整已有数量，第 253、275 行分别检查加购及立即购买条件。起购量为 1、原填 10 件、切换到库存 3 件的 SKU 后调整为 3，是便于理解的示例，不是新增线上故障或实测记录。库存缺失时不设置上限、库存低于起购量时阻止购买的既有边界继续保留；这些是详情数据上的前端约束，不代表重新查询实时库存或后端锁库存。

这版仍以选购为主题：算法说明组合处理，动态禁用说明选择范围，图片、价格与数量说明选择后页面如何变化，购买前校验说明动作条件。没有将普通图集、收藏、分享或提交参数字段全部列入正文，也没有重复第一条完整架构和第四条结算支付流程。编写规则同步这些职责及不扩大的边界，后续不能仅因正文稍长就否定本次补齐的联动范围。

未采用到正文的两项素材继续留作面试入口：

服务端数据与本地选择分离。 详情由 Query 管理，Flow 局部维护选择、数量等状态，更新选项时克隆列表；代码定位见 Flow 第 83 行及 product-sku.ts 第 150 行。详情数据变化后，Flow 第 171 行起会重新初始化规格、数量与主图，因此不能写成“刷新后保留用户选择或草稿”。
局部刷新复用与提示隔离。 Flow 第 191 行起使用 cancelRefetch:false 复用在途请求，已有详情在读取期间继续展示；第 91、198 行起将刷新结果提示关联商品定位身份，切换商品后不展示旧提示。这一身份隔离仅有明确的刷新提示范围，不能扩大为所有加购、购买或异步回调都已有完整迟到保护。该素材属于详情数据读取，未塞入 SKU 正文。

本轮沿用上述只读核对，未修改或运行公司代码、调用真实接口、执行测试或设备回归；源码及测试文件存在不新增通过结论、个人独立设计或熟练度确认。三份个人文档只同步本次第三条与索引，其他条目正文和来源兼容删除决定保持不变。

2026-10-29 第五条按可读性收短（阶段版本，后续已补回关键方法）

本人继续回顾第五条“三端客服聊天”，先要求按实际业务流程解释入口、历史加载、消息收发、图片及业务卡片、咨询切换和断线处理。随后多次指出简历文案绕、读起来费力；AI 先后只调整顺序、换词或展开原因，仍把消息 ID、ACK、去重、重发、幂等及图片任务等机制集中在一段，未真正降低阅读负担。本人要求独立判断后，明确认可下列减少实现细节的版本，并要求同步正文、编写规则和上下文。

当时短稿为：

三端客服聊天： 基于 WebSocket 实现三端共用的客服聊天，支持文字、图片和订单/运单卡片。统一处理消息去重、发送状态和失败重发。切换咨询时取消旧历史请求并过滤过期结果，避免不同会话的消息混入。支持断线重连，恢复后补拉聊天记录。

本次取舍与编写理由：

业务范围与共用能力： 保留 WebSocket、三端共用及文字、图片、订单/运单卡片，让读者知道客服服务于具体业务咨询。订单和运单卡片已有实现依据，不新增任意文件发送或完整 IM 系统的能力范围。
发送处理： 正文概括消息去重、发送状态和失败重发，说明一次消息发送后的反馈与恢复；客户端和服务端消息 ID 的分工、本地回显替换、ACK 超时及同 ID 重发与后端幂等配合，继续保留在 2026-10-22 详述和源码索引中，不要求逐项回填正文。省略术语不等于取消这些设计或验证已完成。
咨询切换： 保留取消旧历史请求与过滤过期结果，直接说明避免旧消息混入新咨询的目的。请求序号、会话标识、发送目标及图片任务回调的具体处理移到面试素材；不能把“取消请求”单独解释为全部时序保护，也不扩大为取消已发送消息或全部图片上传。
断线恢复： 保留重连和恢复后的消息补拉，交代连接恢复后还需要同步记录。有限自动重连、手动入口、补拉范围和核对方式保存在详述中；正文收短不承诺无限重连、消息必达、任意断线窗口都补齐或严格有序。

可读性作为独立验收项：内容覆盖完整后，仍须检查第一次阅读能否理解工作范围、场景与处理方式；每句只承担一类信息，不能只用分号和换词把所有协议步骤挤回正文。必要技术名按当前表达层级选择，本条的 WebSocket、去重、重发、旧请求取消与过期结果过滤、重连补拉足以说明代表性方法，不强制同时保留每种 ID 和 ACK。该取舍只适用于本人本次认可的第五条，不自动精简其他条目，也不推翻此前保留其他项目完整版本的偏好。

本轮业务回顾沿用并只读复核 C:\work\bbdbuy 的公共 chat Flow、draft、API、Query 与三端入口。普通咨询使用默认业务编号，订单以 orderCode、运单以 packingPackageCode 定位；历史记录走 HTTP，实时消息走 WebSocket，图片先 HTTP 上传再发送地址。三端从订单/运单进入后均先显示待发送卡片，由用户点击“发送给客服”；chat-draft.ts 中“等待自动发送”的注释不能覆盖实际 UI 行为。在聊天内选择业务卡片可发送到当前咨询，不等于自动切换会话。关闭时的上下文清理也不等于删除后端聊天历史。这些是回忆业务和面试的补充，不另扩写正文功能清单。

实际实施边界继续保留： 本次沿用本人此前指定的新方案完成式，文案变短不表示新增优化已完成。统一归并以保留本地待确认/失败消息、发送目标和图片任务的完整会话绑定、重连后的补拉核对，尚未按新方案改造或验证；ACK、稳定客户端标识、同 ID 重发及历史关联标识等后端约定仍待确认。2026-10-22 的四项可靠性问题、源码索引和待办均继续有效。本轮只修改三份个人资料文档，没有修改或运行公司代码、调用业务接口、执行公司测试或新增上线及收益结论。

2026-10-29 第四条按可读性收短（阶段版本，后续已补回关键方法）

本人认可第五条减少实现细节后的表达，随后指出第四条也显得复杂。重新按首次阅读的理解负担判断，主要问题在于开头连续解释订单类型、预览编号、结算状态、查询缓存和精确清理，后面再接金额、提交限制、平台接入和结果查询，混合了多层细节。此前对内容范围与事实依据的确认继续有效；本次根据本人新的可读性反馈降低正文的细节层级，建议稿经本人明确授权后写入，不自动调整其他条目。

当时短稿为：

结算与支付流程： 复用购物车与立即购买的结算流程，完成或退出后清理对应数据。适配 Web 跳转与 RN WebView 支付，金额以服务端计价为准，计价或提交期间禁用支付按钮。处理支付回跳与有限轮询，达到轮询上限仍未确认时可手动重查，确认结果后刷新订单、运单与钱包数据。

编写规则与取舍同步如下：

保留结算复用与对应清理。 正文先交代两个购买入口怎样进入共用流程，以及完成或退出时的收尾。订单类型、预览编号、草稿身份及 Query Key 的分工和精确移除继续保留在 2026-10-22 的实现索引中，作为面试展开，不因移出正文就认定代码已删或隔离能力取消。
保留支付接入与操作限制。 Web 跳转、RN WebView 说明各端接入差异；服务端计价说明金额来源，计价或提交期间禁用按钮说明用户操作限制。“金额以服务端计价为准”仍概括使用当前有效服务端预览，不改成任意历史报价都可提交；正在获取、占位或选择不匹配的预览不能提交等判断留在详述。
保留有限轮询及上限后重查。 继续写出回跳、有限轮询、达到上限仍未确认时手动重查和相关数据刷新，不能为了收短再次遗漏上限后的处理。回跳本身不是支付成功证据，轮询本地达到上限不能直接判为支付失败；手动重查针对支付状态，不是重新支付或再次扣款。刷新指相关查询失效和重取，不是前端直接修改后端资金。

“完成”在开头结算流程中指订单创建成功后的前端收尾，不等于已经付款；“退出”指离开本次结算并清理对应前端状态，不等于取消后端已创建订单。草稿只保存当前一份流程标识和编辑上下文，查询缓存按业务身份区分，不将“隔离数据”扩写为同时保存多份完整结算草稿或跨刷新持久化。上述边界与先前只读核对结果一起保留，简述不改变实现范围。

正文收短后仍保留流程、容器、金额、操作限制、结果查询及页面刷新这条业务主线，不再展开身份字段、缓存键、渠道参数及状态字段。此前关于移除 submittingRef 的打算仍是后续计划；本轮没有修改公司代码或证明该计划已完成，也没有运行接口、支付、构建或公司测试，未新增线上结果、后端支付职责或收益结论。技能项目对照及“下一次对话如何接续”的第四条入口同步当前版本，第五条已认可的短稿保持不变。

2026-10-29 第三至第五条的技术方法与简述平衡（当前采用）

本人在第四、第五条收短后进一步指出：第三条既有技术性方法又能简述业务，而第四、第五条改后偏向功能概述，缺少能给读者留下具体印象的技术内容。本人希望同时保留代表性方法与简洁完整的介绍；AI 先前将关键方法与繁琐步骤一并收起，压缩过度。本轮以第三条当前表达作为粒度参照，选出第四、第五条最有代表性的方法并结合用途简述，建议稿经本人“ok先这样改”明确认可后写入。

第三条“SKU 规格联动”正文及规则保持现稿：位运算枚举规格子集与 Path Map 说明组合处理方法，后接规格禁用、图片/价格/数量联动和购买前校验。该方法用于解释实际业务，不由技术名推导算法原创、复杂度或收益；2026-10-23 删除来源兼容及其他实现边界继续有效。

第四条当前正文为：

结算与支付流程： 复用购物车与立即购买的结算流程，按结算标识组织 Query Key，隔离预览缓存并定向清理。适配 Web 跳转与 RN WebView 支付，以服务端计价为准，计价或提交期间禁用支付按钮。处理支付回跳与有限轮询，达到上限仍未确认时支持手动重查，确认后刷新订单、运单与钱包数据。

Query Key 与结算标识一起说明查询缓存及清理范围怎样限定，避免旧流程影响新结算；技术价值来自身份与生命周期的对应，不能把常规缓存组织包装为算法创新，也不把 Query Key 说成全部草稿状态管理。正文不恢复订单类型、预览编号、缓存键清单或清理调用步骤。服务端有效预览、按钮限制、Web/RN 接入、回跳、有限轮询及上限后手动重查继续保留；创建订单后清理不等于已经支付，退出不等于取消后端订单，手动重查不等于重新付款。此前移除 submittingRef 的计划仍未确认完成，本轮不修改公司代码。

第五条当前正文为：

三端客服聊天： 基于 WebSocket 实现三端共用聊天，合并历史与实时消息并去重。消息先本地回显，收到发送确认（ACK）后更新状态；超时重发复用原客户端消息 ID，配合后端幂等处理。切换咨询时取消旧历史请求并校验会话；支持断线重连及恢复后的消息补拉。

本地回显、ACK 和同 ID 重发属于同一条发送链路，依次说明用户反馈、发送确认与超时恢复。本轮只写一种客户端消息 ID，不恢复服务端 ID 分工、回包替换步骤、请求序号、图片接收方或上传回调的完整过程；这些与文字、图片、订单/运单卡片、有限/手动重连等范围继续留作上下文和面试素材，不代表功能已移除。消息合并去重、咨询切换和恢复补拉继续概括；不另外堆入“乐观更新”“状态机”等名称。

两条编写规则同步为“关键方法紧接用途、周边流程简述、字段与步骤留作面试展开”。此前两版短稿保留为阶段记录，不能再将 Query Key、ACK 和同 ID 重发一律视为正文禁写项；也不因恢复关键方法而重新加入全部协议细节。该取舍仅按本人此次明确认可调整第四、第五条，其他条目不自动改写。

实施与证据边界不变： 第五条仍沿用本人指定的新方案完成式。统一归并、完整图片任务及发送目标绑定、重连后的补拉核对尚未按新方案改造或验证；ACK 是否代表持久化、稳定客户端标识范围、同 ID 重发及历史关联等后端约定仍待确认。正文再次提及幂等不构成后端合同已确认或新功能已实现的证明，也不与第二条或 PDA 的幂等实践混同。2026-10-22 四项可靠性问题与源码索引继续保留；本轮只修改三份个人资料文档，不新增公司代码、接口联调、运行测试、上线结果、收益或个人独立贡献结论。

2026-10-29 第六条 RN 表达微调（首句已于 2026-10-30 调整）

本人继续查看第六条，要求参照第三至第五条的表达粒度做一版改进，并追问与原文相比具体改进在哪里。逐句对照后确认：第六条原稿已有底栏测量、父子手势协调、Hermes 配置对齐和分页器替代方案，技术辨识度不需要重新建立；此次只是缩短操作细节、让交互适配、启动兼容和标签页改造分别成句，不包装为新增技术亮点。建议稿曾把“键盘遮挡”改为“键盘交互”，后者偏泛，最终按更具体的原词保留。本人明确要求先按该取舍调整。

当时正文为：

RN 兼容与稳定性： 适配 iOS / Android 安全区与键盘遮挡，通过底栏测量调整输入滚动；子区域横滑时暂停父级手势识别。根据启动日志排查 Hermes 兼容问题，对齐双端运行时与编译配置。针对 Android 标签页崩溃，移除原生分页器，改为仅渲染当前内容并通过手势切换。

编写规则与取舍：

保留具体方法。 底栏测量仍说明遮挡处理的依据，子横滑暂停父级识别仍说明手势怎样协调；Hermes 运行时与编译配置对齐、原生分页器替代方案沿用原文，不为技术感追加组件名、原生类名或算法名称。
收起两处操作细节。 正文省略底栏随键盘移动，以及手势结束或取消后恢复的步骤，并将“测量底栏高度调整输入滚动偏移”收为“通过底栏测量调整输入滚动”。代价是正文少展示这部分交互细节，相关实现与释放边界仍保留在 2026-10-22 的只读来源中，不代表功能删除或不再需要恢复手势。
改善分句。 启动排查与 Android 标签页改造各自成句，避免将不同兼容问题挤在同一个长句里。保留“排查”“针对……改造”的表达，不新增彻底修复、唯一根因或性能收益。

实施与验证状态继续沿用第六条既有事实，不采用第五条的新方案假设：已有配置和组件调整、文档中的高概率诊断、尚待完成的 Release / 灰度验证分别记录。Hermes 原生运行时配置变更需要重建原生壳，不能写成 OTA 已修复；不同 Android 崩溃路径也不合并为全部解决。本轮只同步第六条、编写规则、当前接续入口和技能项目索引，没有修改公司代码、运行构建或测试、调用接口或新增设备验证结论。第三至第五条等其他简历正文保留本轮开始时的版本。

2026-10-30 第六条首句：键盘避让组件与底栏适配（阶段版本，已由同日整条精简替代）

本人指出“适配 iOS / Android 安全区与键盘遮挡，通过底栏测量调整输入滚动”读起来不自然。复核后确认，“适配键盘遮挡”搭配不顺，“底栏测量”“输入滚动”又省略了测量对象与调整用途，上一版压缩影响了理解。本人先认可改为：

适配 iOS / Android 安全区，根据底部操作栏的实测高度调整滚动偏移，避免键盘弹起时输入框被遮挡。

随后本人询问实现方式，回忆起项目使用 KeyboardAwareScrollView，并追问库内部的测量与项目额外测量底栏是否重复。对照公共容器及所用库 1.21.6 版本源码后，确认库负责获取聚焦输入位置和键盘信息、计算遮挡并自动滚动；项目补充的是底部操作栏高度，作为额外避让间距。本人认可在表述中交代工具用途，但指出完整库名过长，最终选择以“键盘避让组件”概括，并明确要求同步正文、规则与上下文。

当时采用的第六条正文为：

RN 兼容与稳定性： 适配 iOS / Android 安全区，使用键盘避让组件处理输入遮挡，并按底栏实测高度设置额外间距；子区域横滑时暂停父级手势识别。根据启动日志排查 Hermes 兼容问题，对齐双端运行时与编译配置。针对 Android 标签页崩溃，移除原生分页器，改为仅渲染当前内容并通过手势切换。

编写取舍：正文保留“键盘避让组件 → 实测底栏高度 → 设置额外间距”，区分库提供的能力与项目针对业务布局的适配。完整库名 react-native-keyboard-controller、组件 KeyboardAwareScrollView / KeyboardStickyView、onLayout 与 bottomOffset 参数留在这里供面试展开；不因省略长库名而删除底栏测量方法，也不将输入定位、遮挡计算和自动滚动包装为自行实现的算法。子区域手势、Hermes 排查和标签页改造沿用上一版。

本轮只读核对的实现与用途：

公共列表容器的底栏测量通过 onLayout 读取整个底栏区域的高度并向上取整，包含安全底栏的内边距；第 340 行将实测高度与页面额外间距相加后传给 KeyboardAwareScrollView.bottomOffset，第 363 行由 KeyboardStickyView 包裹底栏并随键盘移动。
所用库 1.21.6 的滚动判断按窗口高度减键盘高度得到下方可见边界，再结合聚焦输入位置与 bottomOffset 计算滚动；同版本 KeyboardStickyView 通过 translateY 平移底栏。当前布局中，底栏虽原本参与正常排版，平移后覆盖列表的部分仍需额外避让，库不会自动把这个兄弟操作栏的高度从键盘顶部扣除。因此静态核对支持保留底栏高度补偿，不表示所有页面都必须采用同一测量方式。
退款页显式启用键盘模式，备注框聚焦时另加 88 + 8 = 96 的间距；88 为输入框最小高度，8 为安全余量，不是动态测量的输入框完整高度。这一额外余量与底栏实测高度是两项策略，其是否需要缩小仍需单独实机验证。

底栏随键盘移动、手势恢复与释放的详细步骤继续保留在实现来源中；按页面启用及待完成 Release / 灰度验证等范围不变。上述必要性判断依据当前代码与库版本的静态分析，本轮没有运行 App 或做删除补偿后的实机对比，不据措辞调整新增全设备兼容、崩溃消除、测试通过或个人独立贡献结论。本轮只修改三份简历资料文档，未修改公司代码或运行公司项目。

2026-10-30 第六条整条精简（当前采用）

本人继续回顾嵌套横滑、Hermes 启动排查与原生分页库的实现后，要求第六条既简短清楚，也保留关键技术点。此前建议只把父级手势、当前内容和横滑 API 改得更具体，整体长度与结构基本未变；本人明确要求重新精简，不能只换几个词，随后认可下列版本并要求同步正文、编写规则和上下文。

当前正文为：

RN 兼容与稳定性： 适配双端安全区，按实测底栏高度配置键盘避让。根据启动日志排查 Hermes 兼容问题，对齐运行时与编译配置。针对 Android 标签页崩溃，移除原生分页器，仅渲染当前页并支持横滑切换；子区域横滑时暂停外层切页手势。

本次取舍与保留理由：

合并键盘部分的解释。 将组件用途、额外间距和输入遮挡目的收为“按实测底栏高度配置键盘避让”，保留测量对象与配置依据。“配置”仍指接入现有键盘避让能力，不意味着自行实现输入定位、遮挡判断或滚动算法；完整库名、onLayout、bottomOffset 及额外 96 间距的来源继续见前一阶段节。
将两处横滑合到标签页方案中。 仅渲染当前页、支持横滑切换和子区域横滑时暂停外层切页手势放在同一句，交代分页器替代与嵌套交互协调。PanResponder、Context、触点集合与占用计数继续留作面试展开；这些实现已有来源，省略不等于取消功能或技术方法不存在。
保留启动排查的依据与做法。 启动日志、Hermes、运行时与编译配置对齐继续保留，不把兼容排查压成泛泛的“提升稳定性”，也不新增唯一根因确诊或全部启动问题已修复的结论。
限定简述的含义。 双端指 iOS / Android；当前页指当前激活标签的内容，不是请求数据分页中的某一页，也不表示保留了每个标签的全部局部状态。正文由 142 字符缩为 108 字符（含空格和标点，不含条目标题），约减少 24%；这是按内容合并与移位精简，不是仅替换同义词。

本轮回顾补记及实现入口：

子区域触摸处理从 Context 获取父级占用方法，触摸开始时取得一份占用，并用 Set 记录尚未结束的触点；全部触点结束、取消或卸载时释放。同文件第 144 行用 ref 计数并向更外层 Tab 传递占用，释放闭包防止重复减计数；第 171 行在占用期间让父级 PanResponder 不申请接管横滑。计数表示占用份数，不是手指数，也不是禁用父页面全部点击与滚动。实际例子是附加服务图片横滑，避免滑图片时误切外层标签。
升级记录记载 RN 初始化阶段红屏及 iOS TestFlight 启动退出的兼容线索；当前双端 Hermes 选择、Babel 转换、编译器锁定和原生构建配置仍参照本页 2026-10-22 的源码索引。记录与配置已调整不等于两端最终构建及发布验证完成，原生运行时变化也不能通过 OTA 修复。
原生分页崩溃记录对应当时的 SegmentedTabs → react-native-tab-view → react-native-pager-view → Android ViewPager2 / RecyclerView 链路，文档仍将其列为高概率排查路径；不据库名直接断言唯一根因。当前 SegmentedTabs 仅渲染激活标签，点击或横滑达到阈值后更新标签；保留横滑不等于保留内容跟手平移的原生分页动画。

本次只精简三份个人简历资料中的表达与索引。既有代码调整、文档诊断、Android 开发壳及人工反馈、待完成 Release / iOS / 灰度验证继续分别记录；没有修改公司代码、运行构建或测试、完成删除补偿对比或新增设备验证、上线效果和个人独立贡献结论。前五条及第七、第八条等其他简历正文保持不变。

2026-10-30 第七条回顾：历史错误采集与待回忆的定位过程

本人要求回忆当时埋点如何实现、怎样定位到浏览器翻译，并认可先保存本轮解释，后续自行回忆。当时只补记已有个人确认、历史代码核对及待回忆的过程，没有改第七条正文与编写规则；后续采用版本见“2026-10-31 第七条表述调整：DOM 异常线索与翻译定位”。本次保存授权不等于本人新确认了当时使用的全部采集字段、具体异常、复现步骤或验证结果。

已有个人确认

2026-10-19 本人已确认：真实线上曾因 Chrome 自动翻译改写页面 DOM，导致 React 重渲染崩溃；增加埋点后才定位到原因，处理方式是限制浏览器自动翻译并保留站内多语言切换。该历史事实继续有效，当前采集仅在开发环境启用不构成反证。

2026-10-30 同日后续讨论时，本人进一步明确定位依据：“就是那个报dom的错误页面然后排查出来的。”据此补清：错误页报出的 DOM 相关异常是排查线索，再据此定位到浏览器翻译改写 DOM。定位依据和方向已明确，不能再因没有找回原始日志就表述成“定位依据尚未补齐”；仍待回忆的是精确报错原文、具体调用栈及进一步排查或验证的操作细节，不据此次补充认定前文示意的所有字段和对照步骤均用于该事故。

历史代码能还原的采集链路

本轮只读查看 PC 的 bc9d7c85、H5 的 a7270987 迁移快照中的 app/error.tsx、app/api/client-log/route.ts 和 ecosystem.config.cjs。这两个提交为 2026-06-21 迁入 Monorepo 的代码快照，不包含迁移前完整演进，不能据此把迁移日期当成故障发生或埋点首次实现的日期，也不能证明这就是事故当时使用的精确版本。

可还原的链路为：页面异常被 Next.js 错误边界捕获 → error.tsx 的 useEffect 采集 → POST 到自身 Next.js 日志接口 → Node Route Handler 接收并补充信息 → console.error 输出 → 按 PM2 配置进入错误日志。

浏览器采集与上报。 历史错误页读取收到的 error，在 useEffect 中调用 fetch；PC 地址为 /api/client-log，H5 为 /m/api/client-log，请求设置 keepalive: true。这段代码对应页面错误边界捕获后的上报，不代表已经收集了全部异步错误、用户操作轨迹或 DOM 快照。
Next.js Node 接口接收。 两个历史 Route Handler 的 runtime 均为 nodejs，读取 JSON，补充北京时间、时区、x-forwarded-for 和 referer 等信息后，执行 console.error("[client-error]", JSON.stringify(payload, null, 2))；成功返回 { ok: true }，处理异常时输出失败日志并返回 500。这段接收实现只输出控制台，未写数据库，也没有在这里接入独立监控服务。
PM2 日志落点。 历史配置中 NODE_ENV 为 production，PC 的 error 文件为 /var/log/bbdbuy-pc/error.log，H5 为 /var/log/bbdbuy-mb/error.log，并设置 merge_logs: true。这是代码配置声明的日志落点，本轮未连接服务器或读取实际日志，不能据此认定当时执行过哪条日志查询命令、命中了哪条错误。

历史错误页中的字段与用途如下。字段存在说明采集实现具备这些信息，不表示已经找到了那次事故对应的报文或确认本人实际依据了每个字段：

信息	历史字段	可用于理解的范围
异常信息	name、message、digest、cause、stack	查看异常内容及调用线索；本轮没有原始故障堆栈，不能补成某个精确异常或 DOM API 调用。
页面位置	href、pathname、search、route	定位出现异常的页面及查询参数，不等于记录了完整用户操作过程。
浏览器环境	userAgent	判断浏览器及系统信息，不能直接证明用户开启了自动翻译。
用户关联	userName，取用户昵称或默认值	辅助关联反馈，不据此补造当时具体用户或反馈内容。
接收端补充	timestamp、timezone、ip、referer	提供时间与请求来源线索；未读取真实服务器记录。

历史实现与当前状态的区别

迁移快照中的错误上报与接收接口未限制 NODE_ENV。2026-09-02 的相关安全调整（如 a88af082，另有 476cb7a6 对应历史）加入开发环境限制及字段收紧。当前 PC/H5 的 error.tsx 仅在 development 上报 source、name、digest、pathname，Route Handler 在非开发环境返回 404，并对接收字段做白名单和长度限制。不能拿当前文件直接替代历史实现，也不能把历史采集写成当前完整线上监控平台；Sentry、采样和 Issue 聚合仍是既有后续事项。

已明确的定位依据与待补细节

本人现已明确：错误页报出 DOM 相关异常，再据此排查到浏览器翻译。这一定位依据已可用于说明案例；历史代码没有“是否开启浏览器翻译”的字段或 DOM 快照，userAgent 本身也不能证明翻译开启。仅凭现有提交无法逐步还原从 DOM 异常到翻译原因的全部操作，本轮没有找回事故原始日志；这些细节缺失不否定已有个人确认。

以下继续只作为帮助回忆的具体排查思路，尚未确认本人当时按此执行：检查页面是否被外部行为改写，在同一页面对照开启、关闭浏览器翻译，观察 DOM 变化及 React 更新时的表现，以进一步确认关联。DOM 异常作为线索已由本人确认，但具体异常名称、堆栈内容、翻译对照和 DOM 观察不能自动写成已完成的操作、复现或回归记录。

机制参考：Next.js 错误文件说明解释错误边界与错误页入口；React 仓库同类问题记录浏览器翻译改写 DOM 后触发更新异常的案例。这些资料用于理解机制，不是本项目原始日志或本人的操作记录。当前 PC/H5 根布局里的 google:notranslate、notranslate 类与 translate=“no” 仍是已核对的处理配置；页面翻译声明不扩大为强制阻止全部第三方插件。

后续由本人回忆或补找的内容

当时出问题的页面、操作及大致版本或时间。
DOM 相关异常的精确报错原文、具体堆栈，以及实际查看的日志位置。
根据 DOM 异常进一步排查到翻译原因时，采用过哪些具体操作或资料；定位线索与方向不再列为待确认。
是否做过翻译开启与关闭的对照、观察过 DOM，或借助过用户反馈；目前均未确认。
添加翻译限制后验证了哪些页面和浏览器，是否还有遗留情况。

本轮仅记录回顾资料及其索引，没有修改简历正文或公司代码，没有运行项目、复现故障、调用日志接口或新增设备与线上验证结论。后续先从本节继续回忆，不把上述待回忆项标为已完成。

2026-10-31 第七条表述调整：DOM 异常线索与翻译定位（阶段版本，后续补入仓库案例）

本人要求重新整理第七条，简短交代从 DOM 异常到浏览器翻译的定位过程，并表示记不清此前还做过哪些监听排查。本人认可下列版本，要求更新正文、编写规则和上下文，其他监听先记录为待回忆；本节于 2026-10-31 同步采用。随后本人澄清想回忆的是其他线上排障案例，先授权补入仓库状态残留，再要求换为 RN 密码回填后的登录表单卸载问题；最新正文见同日后续“第七条精简与 RN 表单线上排查确认”，本节保留翻译案例的来源和编写依据。

当前正文为：

线上问题排查： 通过错误页埋点采集 DOM 相关异常，据此定位 Chrome 自动翻译改写页面节点引发的 React 更新崩溃；在 PC/H5 限制自动翻译，保留站内多语言切换。

编写规则与取舍：

明确采集入口与定位线索。 将泛称的“埋点定位”写清为“错误页埋点采集 DOM 相关异常，据此定位”。错误边界负责捕获，历史 error.tsx 在 useEffect 中采集上报；“错误页埋点”与本人确认及已有代码入口对应，不暗示自行实现框架错误边界或搭建了完整监控平台。
保持线索、原因与措施的顺序。 DOM 相关异常是已确认的排查线索，Chrome 自动翻译改写页面节点是已确认原因，React 更新崩溃是问题表现；PC/H5 限制自动翻译并保留站内多语言是处理方式。正文不增加精确异常名、具体堆栈或翻译开启与关闭的对照步骤。
限定“限制自动翻译”的含义。 对应页面翻译声明与根布局配置，不保证阻止全部浏览器或第三方插件。配置名、历史采集字段和 PM2 日志链路仍保存在前一节，不逐项放进简历。

其他监听：待本人回忆

本人表示暂时想不起此前是否还有其他监听或排查处理，不把这种不确定回忆写成已经做过。当前能核对的是错误边界及 error.tsx 中的采集上报；对 PC/H5 当前源码、相关公共包和文档、本地可达历史，以及 bc9d7c85 / a7270987 迁移快照作针对性检索，暂未找到 window.onerror、unhandledrejection 或 MutationObserver 等相关接入。

以上是已查范围的结果，不能推出历史从未使用这些机制；迁移前完整开发历史及未保留的临时排查代码不在现有证据范围。上述 API 仅作为后续帮助回忆的检索词，不构成本人已接入的能力清单。

是否使用过全局错误事件、未处理 Promise 拒绝或 DOM 变化监听：待回忆或补找记录。
是否有临时加入的监听、具体触发条件和定位用途：待回忆，不据常见排查做法推定。
DOM 异常的精确报错、具体堆栈、进一步排查操作及复现回归范围：继续待补；DOM 异常作为线索及最终翻译原因已经确认，不退回待定。

前一节中的历史采集链、字段、版本差异和来源边界完整保留。此次只修改三份个人简历资料的第七条相关内容，没有修改公司代码、接入新的监听、运行项目或新增故障复现、线上效果和个人独立贡献结论；其他简历正文不变。

2026-10-31 第七条补充仓库状态残留（阶段版本，已由 RN 登录页案例替换）

本人澄清此前希望回忆的是其他线上问题排查经历，随后要求查看 H5 支付跳转及 RN 仓库提交后的状态残留。核对问题记录和历史代码、解释业务流程及取舍后，本人明确要求将仓库案例补入第七条，并同步编写规则与上下文。该请求确认采用案例，不自动补齐事故发生环境、当时具体排查操作、个人承担环节或真机验证结果。此为当时采用的阶段记录；后续本人要求替换为 RN 登录页密码回填问题，仓库案例现移出正文，以下实现和待验证路径继续作为面试素材。

当前正文为：

线上问题排查： 通过错误页埋点采集 DOM 相关异常，据此定位 Chrome 自动翻译改写页面节点引发的 React 更新崩溃；在 PC/H5 限制自动翻译，保留站内多语言切换。排查 RN 创建运单后返回仓库的选择残留，提交成功时清理草稿，通过成功版本号通知导航栈中保留的仓库页清空跨页勾选，取消返回保留选择。

仓库问题与修复依据

问题记录为仓库状态梳理，问题确认日期为 2026-08-15；历史提交 b374e813 为“修复提交仓库成功后选择和草稿未清理问题”，作者为平台账号 z634521651。日期和账号用于定位代码，不据此确定事故发生时间、本人逐项职责或线上验收。

触发路径。 RN 仓库页跨页勾选包裹，进入提交页填写地址、线路与服务，最终创建运单并进入运单列表；沿历史栈返回仓库页时，已提交的包裹仍可能计入选择数量和重量。这里的提交成功指创建运单，不代表已经完成支付。
保留页面。 进入提交页使用 router.push，原仓库页及其 Hook 实例保留在 Stack；成功后的 router.replace 只替换当前提交页，未结束原仓库页的本地选择状态。
列表与选择分属不同状态。 成功 mutation 已触发仓库列表 Query 失效刷新，但仓库 Flow 开启跨页选择保留。选择 Hook 在该模式下跳过随新列表裁剪旧 ID，因此刷新列表不会自动清空选择。旧 ID 的重量缓存也为跨页选择继续保留。
成功通知。 历史修复通过 completeSubmission() 清理提交草稿并递增 completedSubmissionVersion。仍保留的仓库页 adapter 比较已处理版本，收到新的成功版本后调用 onClearSelection。取消和普通返回不产生成功信号，不清掉用户原先的勾选。
重量与当前演进。 clearSelection 实际清空 selectedIds；重量缓存由依赖选择的 effect 收敛，总重量随之归零，不是一个方法同步直接重置所有字段。当前 RN Store 已改为包装 completeDraft(previewKey)，只有完成仍匹配的当前草稿才递增版本；公共 lifecycle 再精确移除该预览 Query，最后通知和导航。旧请求迟到不会因完成旧草稿而通知原页面清理新流程。

编写取舍与事实边界

保留两类排障的区别。 Chrome 翻译案例保留已确认的真实线上事故和 DOM 异常线索；仓库案例增加 RN 导航栈、本地跨页选择与成功通知的处理。第四条继续概括结算支付流程，不在此复述完整 Query Key 和支付结果规则。
保留方法与业务边界。 正文用“成功版本号通知”说明原仓库页如何收到完成信号，并交代成功清理、取消返回保留选择。Zustand、完整函数名、重量缓存与 previewKey 身份保护留作面试素材，不为技术感堆叠所有实现名。
区分技术记录与个人经历。 问题文档和 diff 能支持根因与代码修复，但没有保留当时逐步排查的日志、断点、具体用户反馈或完整复现过程。线上发现方式、本人参与定位/实现/验证的具体环节仍待补充；此次入稿不新增独立主导、线上恢复或收益确认。
区分已有检查与路径验收。 文档记录过 business build、类型检查及 draft/lifecycle 定向测试通过，同时仍将 RN 跨页选择、取消返回及成功后历史栈返回的真机/模拟器验证列为待完成。本轮仅阅读记录，未运行项目、调用接口或执行这些验证，不写全部回归或线上验收完成。

开发与测试为何可能漏掉（分析与待验证路径）

本人询问仓库问题是否容易在开发测试中遗漏，并认为 Google 翻译更刁钻。解释为：仓库问题依赖跨页选择与旧页面仍保留在导航栈中；如果只检查创建运单成功及落到运单列表，没有继续沿原历史栈返回，就可能遗漏。重新打开仓库页、刷新或重新挂载也可能改变触发条件。这是依据代码还原的漏测风险，不证明当时实际只测了哪些步骤。

后续应核对的路径为：跨页勾选仍正确保留数量和重量；取消或普通返回保留选择；最终成功后沿历史栈返回，数量和重量归零且旧包裹 ID 不再进入下一次预览；下一次提交不复用已完成的地址、线路与服务草稿。这些是待验证路径，不标为本轮已完成。

翻译故障涉及 React 之外的浏览器改写；如果自测仅使用站内多语言，可能没有触发浏览器翻译路径。该分析用于说明其隐蔽性，不新增本人当时的测试方式、翻译对照或全部插件覆盖结论。两类问题分别说明外部环境排查与跨页面状态管理，不因仓库路径属于完整回归应覆盖内容就否定其技术价值。

本轮其他候选的取舍

本人补充 H5 支付旧方案在自己手机上可打开新标签页，部分用户反馈无反应，改当前页跳转后恢复。历史代码已在网络请求前同步预开空白窗口，不能说成异步后开窗丢失用户激活；具体浏览器原因未留存，改同页后跳过内部路由是配套处理，不当作原故障确诊。因此暂留支付面试素材，未补第七条。启动初始化阻塞、购物车数量同步等其他候选也未在本轮入稿。

本轮同步第七条正文、四项编写规则、上下文及技能项目对照。其余简历正文不变；未修改或运行公司代码，也未新增监听、部署、测试或线上验证。

2026-10-31 第七条以 RN 登录页密码回填异常替换仓库案例（阶段版本，后续精简并补充线上来源）

本人追问仓库状态残留是否本应上线前发现，并指出 AI 先推荐入稿、后又因测试应覆盖而降低评价，判断标准前后变化。随后本人回忆 RN 登录页密码自动回填伴随状态销毁或重渲染的问题；核对历史提交后，明确要求用该案例替换第七条的仓库状态残留，并同步编写规则与上下文。

以下为替换时的阶段正文；同日后续采用版本及新增个人确认见“第七条精简与 RN 表单线上排查确认”。

线上问题排查： 通过错误页埋点采集 DOM 相关异常，据此定位 Chrome 自动翻译改写页面节点引发的 React 更新崩溃；在 PC/H5 限制自动翻译，保留站内多语言切换。排查 RN 登录页密码回填后的表单重置，定位前台恢复时的鉴权刷新导致登录表单卸载重建；调整登录入口守卫的渲染条件，后台校验期间保留表单及输入状态。

本人回忆与历史修复

本人最初回忆 RN 登录页使用密码自动回填后，页面出现销毁或重渲染一类的状态问题；同日后续明确确认这是线上发现后由本人排查定位的问题，见后文“第七条精简与 RN 表单线上排查确认”。历史提交 9be8894a29cb012c7c8abc119859ea1af0611042，日期 2026-07-24，作者 zyh，标题为“fix: 修复登录页前台恢复后表单重置”。补丁注释明确说明密码管理器或系统授权返回前台后卸载 Slot，当前代码也保留该修复。个人确认与代码可以对应这一场景；日期、作者和注释不代替当时逐步调试、设备环境或回归结果的记录。

系统界面与前台恢复。 密码管理器或系统授权过程中，App 可能进入 inactive/background。历史 9be8894a^ 的网络同步 Hook 在恢复 active 后等待网络并恢复 Query 焦点，再刷新活跃且过期的查询；当时用户信息 Query 默认新鲜期为 10 秒。当前入口见前台同步。不能说每次自动填充都切后台，或每次返回前台都必定重新请求。
已有状态区分。 修复前的 useAuthStatus 已区分首次加载 isAuthLoading 与已有查询结果后的后台校验 isAuthFetching，后者对应 isFetching && !isLoading。当前状态语义与计算仍如此；此次不是新建两种查询状态，而是纠正其在渲染条件中的用途。
真正卸载表单。 旧登录入口守卫把 isAuthFetching 也纳入 shouldBlockRender。后台校验开始时，认证布局返回 Loading 分支，登录页所在的 Slot 从组件树移除；校验结束后再重新挂载，表单状态因而重置。当前认证布局能对应这条条件分支。普通重渲染本身不会必然清空输入，不能将其和卸载重建混为一谈，也不是 Query 主动清空密码。
实际修复。 登录入口守卫从渲染阻塞条件中移除 isAuthFetching，首次加载及已登录待跳转时的阻塞继续保留。后台鉴权照常执行，已登录重定向 effect 仍等待校验稳定后处理；后台刷新期间维持已有表单挂载及输入状态。修复位置是登录入口守卫，不扩大为所有受保护路由的守卫策略，也不写成禁用了前台刷新或取消了鉴权。

为什么采用以及仓库案例如何处理

保留具体定位链。 本例由系统密码管理器返回引出 AppState、Query 后台刷新与认证布局条件渲染的交互，有明确提交和代码对应；正文保留密码回填、前台恢复、卸载重建及入口守卫渲染条件，完整状态名与 Slot 等留在这里供面试展开。
与翻译案例互补。 Chrome 翻译体现浏览器在 React 之外改写 DOM；RN 登录体现原生系统交互、前后台恢复和鉴权刷新对组件挂载的影响。第二条仍介绍日常请求与会话规则，第六条仍介绍平台兼容；此处只用具体故障说明定位与修复，不复制整套登录架构。
仓库案例移出正文。 原有仓库状态残留记录、代码依据和成功/取消边界继续保留在上一节，作为状态处理的面试素材；其线上环境、个人环节和真机路径验收仍待补，不因本次替换否定实现价值或补写验收结果。
判断标准保持一致。 有技术点不直接等于值得占简历篇幅，应综合个人事实与排查依据、处理过程的代表性及与已有内容的互补。上线前应覆盖属于测试要求，不能据此直接否定排障价值；漏到线上或触发隐蔽也不会自动增加价值。本次替换依据是本人新增回忆、可核对的具体因果与明确改稿要求，不把所有日常缺陷机械判为不值得记录。

仍待补充的范围

具体 Android/iOS、系统和设备版本、密码管理器服务、触发入口，以及密码在回填前后何时丢失的精确表现，历史提交未记录，不自动补齐。
本人已在同日后续明确确认：表单问题在线上发现后由本人排查定位，此项不再待确认。具体使用的日志、断点、对照步骤以及实现、回归环节的分工仍未逐项展开，不将现在还原出的代码链写成当时已执行的完整调试过程。
没有新增事故原始日志、真机或 Release 回归记录、所有自动填充服务均覆盖、全部系统授权流程均已修复及量化收益结论。本轮没有运行公司项目或执行这些验证；现有代码与历史修复不等于本轮复现通过。
Chrome 翻译事故及 DOM 异常线索的既有个人确认继续有效，历史采集与当前开发环境限制、其他监听和待回忆细节均沿用前节边界。

本轮仅替换第七条的第二个案例并同步规则、上下文、接续入口和技能项目对照；其余简历正文不变，未修改公司代码或新增测试、提交、推送及部署。

2026-10-31 Android 导航模式切换后顶部黑条（面试素材，未入正文）

本人回忆部分海外 Android 用户使用底部虚拟三键时出现布局问题，希望通过项目记录还原。对“底部遮挡”和“切换导航模式后顶部黑条”的现象选择了“两种都有，或暂时记不清”；该回答不作为两类现象均已逐项确认的依据。随后本人明确要求把顶部黑条及排查过程保存为面试素材，第七条先不改。

本节依据项目历史文档、提交 diff 与当前实现，区分记录中的现象、当时的机制分析及后续演进。第七条继续采用 Chrome 翻译与 RN 密码回填两个案例；保存资料不新增个人逐项排查、实现或验证责任确认。

历史现象与定位线索

具体症状有记录。 1f651078 及 b31344ef^ 的 AND-001 记载：首次安装后的首次冷启动，顶部区域全黑、系统图标不可见，退出后重新进入恢复。这是项目真机反馈记录，不只是根据安全区代码推测的布局风险。
导航模式与恢复场景。 b31344ef 标题为“修复 RN 导航模式切换后的顶部黑条”。当时文档把首次冷启动、进程重建、全面屏手势与三键导航切换后的窗口恢复列入同类问题；黑色状态栏配合深色图标，表现为时间、电量图标像是消失。未保留具体设备的逐次复现日志，不写成所有三键导航设备都会发生。
明确回归改动。 文档追溯到 7d2fda2：为处理 Google Play 系统栏弃用警告，根 StatusBar 删除了透明背景和 translucent 参数。该改动同时启用 R8，但文档明确将窗口绘制问题与 R8 区分，不能归因为 R8 或公共业务包抽取。

当时的排查与处理演进

2026-07-27，系统栏遮挡与底色处理（098f805a）。 底部操作栏按实际 inset 避让，外层 TabBar/Modal 已处理时避免重复留白；同时设置 Android 浅色窗口背景，收拢状态栏配置。底部按钮遮挡与顶部黑条属于相关系统栏适配中的不同表现，不能用底部 padding 解释顶部黑条。
2026-07-28，首次安装黑顶处理（1f651078）。 新增启动状态栏的白色背景、深色图标及可见配置；根 SafeAreaProvider 从首次布局铺设主题背景，将隐藏 Splash 的时机从字体就绪改为根视图布局完成。目的在于防止原生窗口到 React 视图切换时透出黑底。
2026-07-29，继续追查间歇复现（b31344ef）。 文档指出，窗口底色和延后隐藏 Splash 只能覆盖启动阶段，无法覆盖 Activity 恢复、重新获得焦点或导航模式切换后的窗口装饰重建。当时的机制分析为：旧 Expo SDK 54 / RN 0.81.5 基线仅在 Activity 的 onCreate 应用一次 edge-to-edge，Splash Theme、App Theme、Activity Window 与 JS StatusBar 可能按不同顺序恢复，后续窗口状态因而覆盖前面的配置。
补齐原生与 JS 恢复路径。 当时新增 with-android-system-bars Config Plugin，统一 Splash Theme 与 AppTheme 的系统栏初始配置；在 MainActivity 的 onResume 和重新获得窗口焦点时重新应用窗口布局、显示状态栏并请求 Insets。JS 根布局在 App 回前台时同步状态栏可见性及图标明暗；根布局统一持有状态栏设置，减少页面级重复配置的覆盖。

以上说明历史文档已追到配置回归与窗口恢复机制，且代码有相应处理；不将现在按提交还原的顺序自动写成本人当时执行过的全部断点、日志查询或复现步骤。提交 1f651078、b31344ef 的作者为平台账号 z634521651，账号与签署信息本身不补齐原始个人分工。

当前方案与验证边界

历史原生 Plugin 后来已随 SDK 56 升级移除（ec72d7ea，由 b507382f 合入），当前采用新版默认原生 edge-to-edge 实现，不能把旧 Plugin 当成仍在使用的长期方案。当前仍保留根视图背景、根布局完成后隐藏 Splash，以及 App 前台恢复时的状态栏同步：

当前 AND-001 分析及方案：保留旧基线原因与当前升级后的处理范围。
根布局与 Splash 时机：根视图完成首次布局后隐藏启动屏。
前台状态栏同步：同步可见性和图标明暗。

当前文档仍要求新 Dev Client、Preview 与 Release 产物专项回归：首次安装冷启动、进程恢复、手势与三键导航双向切换、前后台切换后的系统栏背景与图标。历史文档中的“各冷启动 5 次”是验收要求，不是已经执行的次数；不能写成新包全部通过、线上不再复现、Play 弃用警告已清除或全机型适配完成。本轮没有运行公司项目、构建原生包、读取现场日志或执行真机验证。

面试使用与待补充内容

可围绕“黑顶且重进恢复的现象 → 追溯状态栏配置回归 → 启动背景与 Splash 时机的首轮处理 → 窗口恢复机制与生命周期同步 → 升级后的方案演进及验证边界”展开。技术价值来自具体排查依据和跨 JS/原生窗口的处理，不由隐蔽程度或漏到线上本身决定。

当前按本人要求只保留素材，不追加或替换第七条，也不改第六条。后续面试准备优先补充本人参与的定位、实现与验证环节、具体机型和系统版本、实际反馈与复现方式，以及最终发布包的结果；不从“海外用户使用三键”推导用户比例、设备年代或全部受影响页面。

2026-10-31 第七条精简与 RN 表单线上排查确认（当前采用）

本人要求查看第七条完整内容并判断精简空间，随后认可小幅收短稿，要求同步正文、编写规则与上下文。此次精简保留 Chrome 翻译与 RN 密码回填两个案例，正文由 154 字符收为 137 字符（含空格及标点，不含标题），减少重复引导语，不改案例范围与关键技术因果。

线上问题排查： 依据错误页埋点的 DOM 异常，定位 Chrome 自动翻译改写节点引发的 React 更新崩溃；PC/H5 限制自动翻译，保留站内多语言。修复 RN 密码回填后的表单重置：前台恢复时鉴权刷新导致表单卸载重建；调整登录入口守卫的渲染条件，后台校验期间保持表单挂载及输入状态。

新增个人确认

本人先说明“我自己的定位是这个线上出问题后定位出来的”，再澄清“我说的是那个表单的”，最后明确要求把表单问题“线上发现后由我排查定位”的情况记清楚。该确认专指 RN 登录页密码回填后的表单重置：问题在线上发现，随后由本人排查并定位原因。线上发生与个人排查这两项已有本人直接确认，不能再因缺少现场原始日志或完整回忆而退回待确认，也不能仅将其归为项目代码推定的经历。

这次确认不自动延伸到其他 RN 故障、仓库状态残留或顶部黑条。表单案例的历史修复、调用链及源码入口仍见前一阶段记录；具体日志、断点、对照操作、设备及密码服务、实现与回归环节分工、验证范围尚未逐项展开，不新增完整调试步骤、全部服务覆盖或量化收益。

编写取舍与复核

保留排查主线。 翻译案例保留错误页埋点的 DOM 异常线索、Chrome 改写节点、React 更新崩溃及 PC/H5 的处理；RN 案例保留表单重置、前台恢复与鉴权刷新、卸载重建、入口守卫渲染条件和后台校验期间保持挂载，仍能解释问题、原因与修复。
精简重复表达。 将“采集……据此定位”收为“依据……定位”，RN 部分按“问题：原因；处理”组织，收起重复的“排查……定位”和页面名称。后台校验与首次鉴权的职责未改变，不能把简述理解为关闭鉴权或首次等待也显示表单。
按内容判断交叉。 第六条已有 RN 适配和稳定性排查，第七条也可能涉及 RN；平台名称相同不足以判定重复。当前表单案例有已确认的线上来源和个人定位经历，具体说明前台恢复、查询刷新与组件挂载之间的故障，保留于第七条。选材仍综合事实依据、排查及处理的代表性、与已有内容的重复程度和篇幅，不因线上发生或隐蔽就自动入选全部案例。
维持当前范围。 两个案例均保留，不追加 AppState、Query、Slot 等完整调用链术语。Android 顶部黑条、仓库状态残留和 H5 支付跳转继续只作面试素材；第六条及其他简历正文保持原稿。

本轮同步第七条四项编写规则、采用版本、接续入口及技能项目对照，只修改个人简历资料；没有修改公司代码或新增故障复现、设备验证与线上效果结论。

2026-10-31 第八条结构调整与 PM2 处理方法（当前采用）

本人要求查看第八条完整内容，并沿用简短清楚、保留关键技术方法的思路判断优化空间，随后明确认可建议稿并要求同步正文、编写规则和上下文。本次按测试、Web 发布、RN 发布重组，将云效与 EAS 分别放到对应工作中，并补清已有 PM2 案例的处理方法；正文由 215 字符收为 200 字符（含空格与标点，不含标题），主要收益是组织更清楚、做法更具体，不是大幅删减工作范围。

测试与构建发布： 为请求取消、会话清理及结算状态隔离配套单元测试，补充 PC/H5 Playwright 端到端用例。建设云效 CI/CD 流程，Web 按版本目录部署 standalone 制品，以软链接切换版本，配套健康检查与失败回退；重建测试环境 PM2 进程定义，修复发布后仍运行旧代码的问题。建设 RN EAS 构建发布流程并承担双端提审发布；按运行时兼容范围与通道管理 OTA，原生变更升级版本并重新打包。

编写取舍与事实边界

测试说明验证对象。 请求取消、会话清理及结算状态隔离配合单元测试，PC/H5 Playwright 对应浏览器流程验证。已有代表规则足以说明范围，不追加 node:test、全部断言或更多工具名；用例存在与实际执行、完整覆盖、云效测试门禁继续分开。
Web 保留发布方法和具体修法。 standalone 制品、版本目录、软链接切换、健康检查及失败回退共同说明交付方式。PM2 原稿只概括处理过旧入口问题，此次补出已核实的“重建进程定义”，不将其包装为新做的修复。历史为测试环境发布后仍运行旧代码，识别旧 script/cwd 后重建进程定义；正常后续发布仍可 reload，不能写成每次发布都重建。完整诊断、首次接管及回退区别保留在 2026-10-22 的来源节，不移为第七条的线上事故。
RN 保留构建、商店和更新分工。 双端指 Android / iOS；EAS 构建与本人提审发布继续分开理解，不推定 EAS 自动完成商店审核。OTA 仍按运行时兼容范围和通道管理，原生变更须升级版本并重建安装包；Profile、运行时策略及通道配置留作面试展开，不为缩短而删除兼容边界。
现有来源与待验证项不变。 当前表达不新增测试全部通过、真实付款验证、零停机或蓝绿发布、回退必然成功、全部商店审核通过、OTA 灰度或回滚演练等结果。HTTP 健康检查不等于完整业务验收；第六条 RN 改造的 Release / 灰度验证范围仍按原记录。个人职责也不因重新组织文案而扩大为全部测试和发布环节均独立完成。

本轮同步第八条四项编写规则、阶段与当前入口、接续第 14 项及技能项目对照；其他简历正文保持原稿，包括第七条及其 RN 表单问题的线上来源与本人排查确认。未修改或运行公司项目、触发流水线、执行发布或新增远端验证。

2026-11-03 运营后台参照主项目完善表达（阶段版本，已调整）

本人要求“以第一个项目编写为参考，修改一下第二个后台的项目”。本轮沿用主项目的简介、个人职责、技术栈及逐条“目的、记录、不记录、理由”规则，保留后台原有五类工作，按业务场景与关键方法整理，不机械套用八条结构、三端架构或首个项目的规模与上线背景。

本节保留 2026-11-03 的整理依据；简介沿用同日实际业务范围，第一条短版来源见 2026-11-05 的工程组织记录。当前个人职责、六条组织与编写规则以“2026-11-07 运营后台按业务组件与交互重组（当前采用）”为准。

当前组织与改写依据

简介补清入库验货、上架、拣货打包和发货等履约环节，原分箱条目中的业务范围移到此处集中说明。新增个人职责行，依据现有工作经历中的后台主要前端建设与迭代范围以及已采用案例，不新增全程独立完成或后端责任。技术栈补出商品子表实际使用的 Ant Design，与 Pro Components 各有对应。

页面组织与订单表格： 基于 Umi Max 组织路由、布局与公共请求配置；使用 ProTable 主表嵌套 Ant Design Table 商品子表，按订单、商品层级展示业务数据。
仓储分箱与条码： 基于 React DnD 实现拖拽分箱，支持扫码分配与重复提示，提交前校验未分配包裹及空箱；封装 JsBarcode 生成 Code 128 条码，支持批量打印与补打。
客服组件与连接管理： 封装 ChatBox 与消息气泡组件，复用于客服会话和采购单内联系客户；接入全局 WebSocket，同步会话列表与未读提醒，处理订阅清理、有限重连及退出清理。
退款与作业统计： 实现退款批量审核、驳回及财务记录导出；基于 ECharts 展示验货、拍照、上架、拣货与打包等阶段的作业绩效。
登录依赖与发布检查： 拆分登录、会话与业务依赖，保留登录页已有会话检查，通过 React.lazy 与动态 import 按需加载头像、WebSocket 和客服服务。关闭发布 Source Map，在制品脚本中检查映射文件及引用残留，检出残留即终止制品构建。

条目	保留、补充与移位的理由
页面组织与订单表格（原“订单与商品表格”）	用一句 Umi Max 职责说明后台基础，再给出具体嵌套表格。本人 2026-10-17 已确认“订单套商品”；本轮补 ProTable / Table 作为实现依托，不把一般表格展示包装为算法、虚拟滚动或性能优化，也不因参考主项目就新增未经确认的框架选型经历。
仓储分箱与条码（原“仓储分包与条码”）	“分箱”明确业务含义，避免与代码按需加载混淆。保留拖拽、扫码重复提示、未分配与空箱检查、Code 128 及打印补打；React DnD 负责拖拽，扫码是另一个输入入口，不把两者都归于拖拽库。履约页面范围移至简介，不删除已保留的业务经历。
客服组件与连接管理（原“客服通信”）	先交代客服页和采购单内复用，再说明连接、订阅与未读状态。与三端聊天的发送确认及重发案例侧重点不同；只保留本后台实际的有限重连和退出清理，不借用三端新方案的完成式假设。
退款与作业统计	原稿的业务范围和 ECharts 用途已经清楚，仅分开业务处理和图表展示两部分；不为了每条都显得更复杂而补资金算法或图表内部生命周期，也不让工程条目挤掉已有业务。
登录依赖与发布检查	补 React.lazy 和动态 import 说明加载方法，继续保留已有会话检查和 Source Map 产物失败检查。两部分分别成句，不把依赖拆分或禁用源码映射提升为接口保密或服务端权限设计。

来源、实现入口与个人确认范围

已采用的后台主要前端职责与既有案例继续有效；本轮代码核对用于说明方法，不自动新增逐项独立设计、完整验证或线上收益。页面组织与请求处理可对应旧简历中的 Umi Max 工作范围及当前配置；嵌套展示有本人直接描述，新增库名不等于新增业务交互经历。登录改造另有本人提供的 Codex 对话和此前只读核对，详见本页“后台登录依赖与发布检查的补充依据”。

实现范围	本轮只读入口与边界
页面基础与嵌套表格	Umi 配置接入路由、布局及请求插件，公共请求配置接入异常处理；订单主表的 ProTable 在第 513 行内嵌 Table，子表数据来自订单 products。没有增加跨级勾选、合并单元格、虚拟滚动、展开性能或首屏收益；订单页 ProTable 自带分页设为 false，不将页面分页直接归给该组件。
分箱与条码	分箱弹窗扫码匹配未分配包裹并检查重复，第 329 行起检查未分配包裹与空箱；Code 128 工具使用 JsBarcode，作业列表收集选中包裹生成打印内容。前端校验不证明后端库存锁定、全链路防重或设备打印全部通过。
客服组件与连接	ChatBox 组合消息展示，复用于客服页和采购聊天弹窗；聊天模型注册消息及重连订阅并清理，WebSocket 管理实现有限重连、订阅取消及关闭清理。当前重连间隔 3 秒、上限 3 次，稳定连接 5 秒后重置计数，仅作为参数记录。模型重连回调清消息缓存和选中会话，不写成重连自动补拉全部历史或无损恢复。
退款、财务与统计	退款列表有批量驳回和状态更新，消费记录调用导出接口，绩效图表使用 ECharts。按服务端能力标记筛选、金额处理和图表生命周期只作源码观察，不据此新增个人资金计算、权限设计或效率成果。
登录加载与制品检查	应用入口使用 lazy 加载头像，第 38 行动态引入会话服务，第 47 行保留登录页会话识别，第 79 行起动态加载 WebSocket；聊天模型按需引入客服服务。发布配置使用 devtool: false，制品脚本对 .map 文件和 JS/CSS 内 sourceMappingURL 引用作失败检查。不能据此声称所有业务接口集中于唯一异步包，或未登录无法下载业务 JS。

后台上线日期、独立业务规模、逐项个人设计及验证分工仍按既有来源界定，不直接恢复旧简历的页面数量、作业人员与吞吐量。历史构建及本机模拟结果不扩大为真实后端联测、全仓检查通过或线上验收。本轮只读公司项目文件，没有修改公司代码、安装依赖、运行构建测试、调用接口或执行发布。

本轮更新求职简历的后台段落、八组编写规则（简介、职责、技术栈及五条工作）、本页上下文及技能项目关联；主项目、PDA、TMS、工作经历和技能正文保持原稿，日期更新为 2026-11-03。后续按需要逐条细化后台案例，不将这次基于既有素材的改写当作新增个人确认。

2026-11-03 职业概述改为完整职业背景

本人指出原概述几乎全部取自当前公司的跨境电商与多端工作，更像当前岗位摘要，而不是完整职业概述，并确认按本轮建议修改。现改为先后概括物流 TMS、仓库 PDA 与跨境电商平台经历，以 PC、H5 和移动端概括开发范围，再用“从业务页面开发、接口联调及上线问题处理，逐步扩展到多端业务复用、公共请求治理、移动端稳定性与构建发布”呈现职责发展，保留已确认的新人带教、技术方案把关及代码评审经历。

本次调整只重组已有事实，不表示早期经历与当前职责具有相同深度，也不新增工作年限、负责人职级、独立主导、业务结果或熟练度评级。具体框架、实现方法与项目责任仍由技术能力、工作经历和项目经历分别说明，职业概述不恢复旧版的完整能力长串。

同日本人确认删去职业概述开头的“前端开发工程师，”，直接以“以 React / TypeScript 为主要技术方向”起句。页首已写明求职方向，此处省去重复岗位名称；这是版面内的措辞精简，其余概述内容及事实范围保持不变。

2026-11-03 技术能力两处措辞调整

本人确认仅调整技术能力两处：Web 开发中的“具备 Ant Design、HeroUI 等 UI 组件库的实际使用经验”精简为“使用 Ant Design、HeroUI 等 UI 组件库”；状态、请求与通信中的“请求封装”补为“基于 Axios 的请求封装”。前者保留组件库使用范围，后者明确已有公共请求实践的工具依据，关联 BBDBUY“公共请求与会话管理”。六条分类、其余简历正文及技能确认边界保持不变，不新增熟练度评级或个人职责。

2026-11-03 运营后台简介按实际业务范围调整（当前采用）

本人要求结合后台实际业务重新审阅简介，随后明确认可建议稿，并要求同步编写规则和修改上下文。当前采用：

服务于 BBDBUY 跨境代购与国际集运业务的内部管理平台，面向采购、仓储、客服与财务团队。覆盖订单采购、入库验货、出库发货及客服售后，提供会员与财务管理、营销和物流配置及仓储作业统计。

原简介已有业务没有事实错误，此次调整补清后台与 BBDBUY 代购、集运业务的关系，并平衡各类业务的详略。将仓储细分环节概括为入库验货、出库发货，客服售后承接原有客服及退款范围；补出会员、财务及运营配置，避免简介过度偏重采购和仓储。活动、优惠券、线路和运费模板只作归类依据，正文采用“营销和物流配置”，不展开全部菜单。

本次直接读取后台项目说明、路由配置，并针对订单、采购、分箱、客服、退款、财务、绩效及运营配置页面核对业务范围。新增范围可对应会员管理、充值和消费记录及提现审核、活动配置和物流线路配置；优惠券和运费模板的模块入口见路由配置。此次为定向只读核对，不是全仓逐文件审阅，也未运行公司项目、调用接口或新增上线验收结论。

简介的“目的、记录、不记录、理由”同步按业务定位、使用岗位、履约主线与运营管理范围更新。源码支持的是项目功能范围，本人认可文案不自动确认全部模块均由本人独立设计或实现，不新增熟练度、规模及收益。同步更新技能与项目对照中的后台简介说明，既有五条工作及技能关联保持原有事实边界。

2026-11-03 运营后台个人职责概括（阶段版本，已调整）

本人认可将个人职责按承担范围精简，并明确要求同步编写规则和修改上下文。当时采用如下版本；2026-11-07 已结合业务组件定制与复用补充调整，最新表述见该日“运营后台按业务组件与交互重组（当前采用）”：

个人职责： 承担后台主要前端建设与迭代，负责业务页面开发、公共组件封装及前端工程优化。

保留“承担后台主要前端建设与迭代”的既有定位，将后半句概括为业务页面开发、公共组件封装和前端工程优化，保持职责行的表达层级一致。客服页面与组件对应前两类工作；登录依赖拆分、按需加载及发布制品检查对应工程优化。上述具体案例继续保留在后文，本次没有删除相关经历，也不新增工程建设范围、全程独立完成、后端职责、验证结果或收益。

个人职责的四项编写规则同步说明概括范围与保留理由，技能与项目对照补记上述关联。此次为已有职责的表达精简，个人承担、方案选择、验证及上线分工继续按既有来源界定；项目简介、技术栈和五条具体工作沿用当前版本。

2026-11-05 运营后台第一条：后台工程组织与业务页面（阶段版本，已调整）

本人希望参照第一个项目先交代工程基础、再展开代表业务的思路，并明确认可第一条建议稿，要求同步编写规则和修改上下文。当时采用如下版本；同日后续已将表格移为订单业务素材，最新版本见下文“运营后台第一条：后台工程组织与公共能力（当前采用）”：

后台工程组织与业务页面： 基于 Umi Max 组织路由、布局与业务页面，统一请求配置、公共请求头和异常提示，处理登录态初始化与失效跳转；使用 ProTable 订单主表嵌套 Ant Design Table 商品子表，按订单、商品层级展示业务数据。

原“页面组织与订单表格”扩展为工程组织与公共能力概述，补清已有请求及登录处理，再以订单与商品嵌套展示承接业务页面。第一条提供整体背景，第五条继续解释登录依赖拆分、按需加载及发布制品检查，两者层级不同；本次保留五条结构，没有新增独立架构主导或框架选型经历。

本轮对照的源码入口与范围：

Umi 配置接入路由、布局、初始状态和请求插件；应用入口通过 getInitialState 查询当前用户，在已有会话或未取得用户信息时处理页面跳转，并导出公共请求配置。
请求异常与拦截配置设置公共语言、币种、时区和端标识请求头，提供业务及请求异常提示；公共错误处理中的 401 分支提示后跳转登录页。部分请求使用 skipErrorHandler，因此不表述为全部请求均执行相同提示或跳转。
会话查询调用用户详情接口并跳过公共错误处理；初始化查询的异常由应用入口捕获，当前不严格区分网络异常和未登录。源码未体现三端项目的并发 401 去重、查询缓存隔离或幂等重试，不将这些能力迁入后台表述；登录跳转也不等于完整角色或数据权限控制。
订单页面使用 ProTable 的展开区域嵌入 Ant Design Table，商品数据来自订单 products。继续仅概括分层展示，不新增跨级勾选、虚拟滚动或性能结果。

本次补充用于说明已有项目实现，个人范围仍沿用主要前端建设与既有确认，不将本人认可文案扩大为每项方案的独立设计、完整验证或上线成果。正文及四项编写规则、接续入口和技能项目关联同步更新；本轮没有修改或运行公司项目，后台发布方案仍未补入简历。

2026-11-05 运营后台第一条：后台工程组织与公共能力（当前采用）

本人追问第一条为何仍写 Table，随后明确认可将标题改为“后台工程组织与公共能力”，表格部分先保留为订单业务素材，并同步编写规则和修改上下文。当前采用：

后台工程组织与公共能力： 基于 Umi Max 组织路由、布局与业务页面，统一请求配置、公共请求头和异常提示，处理登录态初始化与失效跳转。

第一条集中说明工程组织、公共请求与登录处理，订单和商品嵌套展示移入下方候选素材，暂不另增正文条目。第五条继续说明登录依赖拆分、按需加载和发布制品检查，保留五条结构。技术栈仍保留实际使用的 Ant Design Pro Components，表格案例移出正文不改变已有工具使用事实。

正文四项编写规则及技术栈规则的对应说明、接续入口和技能项目关联同步更新。实现依据及个人范围沿用上方阶段记录，不新增个人独立贡献、完整权限体系、三端同等请求治理或验证结果；订单素材仅保留已有分层展示事实，后续按实际业务需要选用。

2026-11-05 运营后台作为补充项目精简（阶段版本，已调整）

本人比较两个项目后，认为后台继续展开请求和登录处理容易重复，明确要求按补充项目的定位精简，第一条保留当前短版，并同步编写规则和修改上下文。本次调整的是篇幅与案例权重，原有主要前端建设范围及事实依据继续保留；不将本人对项目技术含量的评价转为熟练度或个人能力结论。

简介、个人职责、技术栈及五条结构保留。当前正文为：

后台工程组织与公共能力： 基于 Umi Max 组织路由、布局与业务页面，统一请求配置、公共请求头和异常提示，处理登录态初始化与失效跳转。

仓储分箱与条码： 基于 React DnD 实现拖拽分箱，支持扫码分配，提交前校验未分配包裹及空箱；封装 JsBarcode 生成条码，支持批量打印与补打。

客服组件与连接管理： 封装客服组件，复用于客服会话和采购单内联系客户；接入全局 WebSocket，同步会话与未读提醒，处理有限重连及退出清理。

退款与作业统计： 实现退款批量审核、驳回及财务记录导出，使用 ECharts 展示仓储各环节作业绩效。

登录依赖与发布检查： 拆分登录、会话与业务依赖，保留已有会话检查，通过 React.lazy 与动态 import 按需加载业务模块；关闭发布 Source Map，构建时检查映射文件及引用残留，检出即终止构建。

第一条承担工程基础说明，不采用此前讨论过的请求拦截、401 和 getInitialState 详述稿；该稿只是可选建议，未写入正文。仓储条目保留拖拽、扫码、提交校验和条码输出，客服条目突出跨业务入口复用并简述连接管理，退款统计概括业务范围，第五条保留具体加载方法及制品检查的失败条件。主项目继续展示较完整的架构与复杂案例，后台以差异明确的作业场景和工程改造补充，不追求相同篇幅。

收起的细节继续作为实现或面试素材：分箱的重复扫码提示与 JsBarcode 的 Code 128 制式；ChatBox、消息气泡组件、会话列表同步和订阅清理；验货、拍照、上架、拣货与打包等统计环节；React.lazy 加载头像、动态 import 加载 WebSocket 和客服服务，以及登录页已有会话检查。第五条中的“业务模块”是对这些加载对象的概括，不表示全部业务统一分包；“构建时检查”仍指制品脚本检查 .map 文件及 sourceMappingURL 引用，检出残留使制品构建失败。订单嵌套表格当时作为候选保留，2026-11-07 已并入第二条采购物流编辑案例。

各条四项编写规则、接续入口与技能项目关联已同步。个人实现、方案选择、历史构建及模拟、真实联测与上线验证的边界沿用既有记录；本次仅精简文案，没有运行或修改公司项目，也不新增性能、安全、资金计算或消息可靠性成果。

2026-11-07 运营后台按业务组件与交互重组（当前采用）

本人先要求按项目实际梳理业务，再讨论亮点与排序；随后补充“订单表又套商品”“填物流的时候，又有 SKU 回填，又有取值”，并明确认为后台的主要特点是基于 Ant Design Pro 改造的复杂 UI 组件较多。讨论选材依据后，本人要求“先把完整的改一版出来”，本轮据此更新第二个项目正文、编写规则和技能项目关联。

当前定位与排序

以复杂业务数据的展示、编辑和操作为主线：先由采购、仓储及售后业务确定前端要处理的关联关系，再用回填、编辑值同步、分配状态、条件联动和业务校验说明方法。复杂组件在这里指基于 Ant Design / Pro Components 的业务定制，不表示修改组件库源码、建设统一表格引擎或完整组件库。

第一条保持原有短版，第二条以采购物流编辑为主要案例，第三条展示仓储分配交互，第四条展示渠道规则与批量操作，第五条补充统计展示，最后由具体工程改造收尾。排序依据阅读层级和案例代表性，不要求与实际业务流转顺序一致；物流编辑、分箱和售后承担主要篇幅，后台仍作为主项目的补充。

项目简介保留此前确认的业务范围；个人职责将“公共组件封装”调整为“业务组件定制与复用”，对应本人本轮补充及已有实现。技术栈继续保留实际使用的工具，WebSocket 不因客服独立条目移出而删除。当前六条如下：

后台工程组织与公共能力： 基于 Umi Max 组织路由、布局与业务页面，统一请求配置、公共请求头和异常提示，处理登录态初始化与失效跳转。

订单分层展示与采购物流编辑： 使用 ProTable 与 Table 按订单、商品层级组织数据；基于 EditableProTable 封装物流编辑组件，支持商品规格与数量选择、已有包裹回填、编辑值同步及提交数据转换。跨物流记录汇总商品分配数量并校验采购数量上限，复用于采购和验货页面。

仓储分箱与条码作业： 基于 React DnD 实现拖拽分箱，拖拽与扫码共用包裹分配逻辑，支持箱间移动及移回待分配区；提交前检查未分配包裹和空箱，使用 JsBarcode 生成条码，支持批量打印与补打。

售后表单与批量处理： 按淘宝、1688、微店的渠道差异组织售后申请表单，联动退款类型、收货状态、退款原因及金额范围，支持退货物流登记；客户退款按接口返回的可操作标记筛选批量受理、驳回对象。

仓储绩效与目标展示： 使用 ECharts 展示仓储各环节的员工对比与个人作业趋势，支持日期、员工和作业环节筛选；按历史目标调整记录划分查询区间，展示对应目标及生效日期。

登录依赖与发布检查： 拆分登录、会话与业务依赖，保留已有会话检查，通过 React.lazy 与动态 import 按需加载业务模块；关闭发布 Source Map，构建时检查映射文件及引用残留，检出即终止构建。

选材与移位

订单素材回到业务条目。 2026-11-05 从工程概述移出的订单、商品分层展示并未被否定，本轮将其作为第二条的业务背景，物流编辑作为主体。本人此前确认过“订单套商品”，本轮进一步指出物流的规格回填和取值；不把嵌套表格本身包装为性能优化。
保留完整的数据处理过程。 物流编辑覆盖接口数据回填、表格中自定义商品数量选择、值变更传递、提交转换和跨行数量校验，并在采购、验货两个入口复用。正文保留 EditableProTable 及关键约束，具体 React API 和字段留作面试素材。
仓储保留操作与状态。 在已有分箱、校验和打印案例上，补清拖拽与扫码共用分配逻辑、包裹可在箱间移动或退回待分配区。扫码查找目前针对待分配区，已分配条码走重复提示，不写成扫码也能任意箱间移动。
售后与统计分开。 原“退款与作业统计”拆成两条。售后区分采购平台申请与客户退款批量处理；统计独立说明维度切换及历史目标展示。财务导出移为候选素材，原有工作事实保留。
按互补程度控制篇幅。 客服组件及连接管理保留为候选，既有实现和个人来源不失效；主项目已经较充分呈现聊天。优惠券联动、商品 SKU 编辑也保留为候选，本版优先选取物流编辑、分箱和售后，避免仅按菜单扩充条数。

实现依据与面试展开边界

案例	核对到的实现	表述与事实边界
订单与物流编辑	订单主表展开商品 Table；采购回填与提交把 packages/items 转为可编辑的物流记录、商品明细 ID 和数量。物流编辑组件通过 value/onChange 接入父页面，以自定义商品数量选择器编辑单元格，保留编辑行标识并向上转换商品数据；暴露 validate，在有未保存行时阻止提交，并跨物流记录汇总商品数量、校验采购上限。验货页复用同一组件。	规格来自订单商品展示，匹配键是商品明细 ID，不扩大为跨订单统一 SKU 身份设计。数量规则是不能超过采购数量，不表示所有商品必须全部分配；不新增全链路数据一致性、库存锁定、虚拟滚动或性能结果。
分箱与条码	分箱组件使用共用 movePackage 更新待分配池和目标箱；拖拽可移动或移回，扫码匹配待分配包裹后调用同一逻辑。提交时检查剩余包裹和空箱，按目标箱生成包裹明细 ID 集合；JsBarcode 批量打印与补打沿用此前核对。	不推定最优装箱算法、后端并发库存控制或打印设备验证；PDA 的广播扫码、实物拣货和上架提交仍属于 PDA 项目。
多渠道售后与客户退款	淘宝表单按退款类型及收货状态查询原因和费用模板；1688 表单按选中商品及货物状态读取原因和退款预览；微店表单按是否收到货筛选本地原因。商品退货页登记退货物流；客户退款按 canRejected、canAcceptance 等标记筛选批量操作对象。	原退款审核经历继续有效；新增渠道细节来自源码，不自动确认各渠道均由本人独立设计。各渠道接口、原因来源和金额控制不同，不写成通用规则引擎或统一金额算法；可操作标记来自服务端，不归功为前端权限设计。
绩效与历史目标	绩效页面查询历史目标并组织员工对比和个人趋势；目标分段按变更日期排序、截取查询范围并合并相邻同值区间，图表配置生成含生效日期的目标线标注。	原 ECharts 作业统计经历继续有效，历史目标处理是本轮源码补充。首条目标记录晚于查询开始时，当前实现向查询起点延伸，不能据此宣称完整历史精确还原；图中目标线并非逐日精确阶梯曲线。工作量由接口提供，不新增统计后端、薪酬计算或效率结果。
工程基础与依赖改造	Umi 配置、公共请求、初始用户查询及失效跳转沿用此前核对；登录/会话/业务依赖拆分、React.lazy、动态 import 和 Source Map 制品检查沿用本人提供的历史对话与实现依据。	第一条不扩大为完整权限体系或三端同等请求治理；第六条不新增首屏速度、包体量化收益、接口保密、全部业务统一分包或线上验收结果。

业务阅读范围与个人事实

本轮讨论先只读核对后台的订单、采购、入出库、售后、配置、客服、财务和绩效相关页面及接口，并针对客户侧创建转运订单、仓库包裹提交运单、运单付款，以及 PDA 收货、拍照、上架、拣货、发货进行交叉核对。业务理解用于选材，不表示整套业务或其他端的实现均属于后台个人贡献。

客户商品订单、采购单、国内物流包裹、库存包裹与出库包装单元需要区分；转运入口可不经过平台采购。运费时序存在资料差异：后台客服话术支持打包完成后支付，客户帮助页仍描述先付押金再打包，实际押金分支未核验。本轮简历未加入该时序结论，也未用业务流程图推定服务端自动状态联动。

本人补充了复杂业务组件的工作特点及订单、物流编辑的具体场景，已有后台主要前端建设、分箱、退款、统计和登录改造来源继续有效。本轮采用的是本人授权整理的项目表达，代码核对用于补清方法，不由改稿授权自动新增每项独立设计、熟练度、完整测试或上线效果；尤其多渠道售后和历史目标的逐项分工仍按后续事实补充。

本轮仅修改简历及两份维护文档，没有运行或修改公司项目、调用业务接口、实施代码改造、提交、推送或部署。

保留为候选的案例

下列素材来自旧简历或本人后续补充，具体来源与确认范围分别记录；旧简历素材保留不等于已在本次核实个人职责。按具体岗位的相关性与案例重复程度决定替换或补充。SKU 规格联动和三端客服聊天已于 2026-10-13 恢复至当前正文，不再列为候选。

后台客服组件与连接管理（2026-11-07 移作候选）： 原条目“封装客服组件，复用于客服会话和采购单内联系客户；接入全局 WebSocket，同步会话与未读提醒，处理有限重连及退出清理”保留为已有素材。ChatBox、聊天模型和全局 WebSocket 的依据见 2026-11-03 核对记录；当前重连回调清缓存和选中会话，不支持据此表述历史自动补齐、ACK 幂等重发或消息必达。移位是本版篇幅取舍，不否定组件复用价值。
后台财务记录导出（2026-11-07 移作候选）： 充值、消费等财务记录查询和导出沿用原简历及此前接口调用核对，作为后台财务业务素材保留。不扩大为资金算法、自动对账或后端账务建设。
后台优惠券规则与表单联动（2026-11-07 新增候选）： coupon/model.ts 和配置页有券类型、领取来源与适用端组合限制，切换时清理失效字段，提交时按当前条件组织参数。用于补充动态表单能力，当前未单独入正文；项目实现不等于新增个人独立负责确认，也不写成服务端权益引擎。
后台商品规格与 SKU 编辑（2026-11-07 新增候选）： GoodsModal.tsx 有规格组合生成、编辑回填、SKU 字段编辑与上下架校验，可体现运营录入侧的交互。修改规格后的保留逻辑仍有按行索引取旧数据的实现，不能写成新增、删除、重排规格时均能准确保留 SKU 数据；本版优先选采购物流编辑，具体个人分工与验证范围另核实。
商品分享与邀请链路： App Links / Universal Links、来源及邀请参数、H5 兜底和回跳地址校验。适合 RN 或增长链路相关岗位，可替换交易流程条目。历史登录回跳素材按端及版本判断；固定 develop 的 RN 登录落点已改为首页，不把旧回商品页方案当成当前能力。
升级兼容： 旧版记录 Expo SDK 54→56、React Native 0.81→0.85、NativeWind 2→4。需要讲清个人职责、遇到的兼容问题与验证过程后再选用。
其他 TMS 内容： 配置化合同、PDF 生成与打印、国际化。针对对应岗位再选取，避免恢复完整功能清单；后台退款、财务导出与作业统计已恢复到当前正文。
其他业务与状态案例： 购物车数量输入与后端确认、语言币种刷新与账号退出的区别、赠品领取资格与本地计时、共享后删减多余工厂、商店强制更新与 OTA 协调。具体变化、日期和边界见本页完整历史复核节；当前作为面试或后续替换素材。PC 的 AI 辅助 Figma 重写已采用；旧 Web Token 与渐进主题表述已于 2026-10-21 移出正文，新的 PC 主题与样式方案作为补充素材，状态及后续两端范围见同日第一条更新。
RN 仓库提交后状态残留： 导航栈保留页面、跨页选择与 Query 数据分离、成功通知清理及取消返回保留选择；曾短暂补入第七条，2026-10-31 按本人要求换为 RN 登录页密码回填异常。实现与待验证路径保留在同日仓库阶段记录，当前作为面试素材，不将其事故环境或个人环节自动补齐。
Android 导航模式切换后顶部黑条： 冷启动黑顶与图标不可见、状态栏配置回归、Splash 时机及窗口生命周期同步；完整记录见“2026-10-31 Android 导航模式切换后顶部黑条”。本人要求只作面试素材，第七条不变；旧原生 Plugin 已随升级移除，个人环节与最终包验证仍待补充。

下一次对话如何接续

讨论简历时，先读本页与“张育华的求职简历”，再按需要查“职业经历与 BBDbuy”。旧简历用于追溯原文，旧版面试练习资料已于 2026-10-21 按本人要求移除。后续面试准备以当前简历和已确认事实为起点，不能自动将改稿内容视为已经掌握或逐项确认。

本次已经完成精简、重排和上下文记录。以下属于后续核实入口，不预设新的日程，也不自动标记周计划完成：

核对任职首尾月份、公司名称对应关系，以及教育起止时间；三个月任职的主动省略继续遵从本次选择。
对主项目各案例及后台登录依赖改造，分别补充本人承担的方案选择、实现、验证和上线责任，尤其是 RN 排障、SKU、结算支付、聊天和发布上架。
核对旧简历保留的浏览器扩展、后台、PDA 和 TMS 表述，区分参与、负责与独立完成的程度。
PDA 广播模式等实现已于 2026-10-09 根据本地代码补入；UTS 原生水印模块于 2026-10-13 补入，本人已确认实现并测试跑通。2026-10-21 本人已确认首次未收到响应后复用请求 ID、后端返回相同响应的幂等重试场景；BBDBUY 第二条也已按本人最新要求以已实现功能写入同 ID 幂等重试，表达来源及前次进度陈述见同日最新记录。后续可补充具体职责、测试设备与覆盖范围、原生模块正式业务接入、幂等适用接口与上线结果。
如需补业务指标，先确认来源、统计时点和口径，再决定保留哪些数字。
当前求职方向以 2026-10-17 本人最新澄清为准：前端开发工程师，岗位名称不带 React 或 RN 限定。React 仍为已有主要技术栈，后续根据具体投递岗位调整案例权重；薪资、公司类型、意向城市等其他岗位条件尚未全部确认。
Next.js 的最新采用表达与完善建议见本页“2026-10-22 第一条补充 Next.js 选型依据与实际用途”；SSR、PC 首页、初始化门槛与 PM2 细节继续见“2026-10-21 Next.js、SSR、首页初始化与部署并发讨论”。接续时区分本人已认可的当前选型复盘、不确定的原始回忆、已有实现与可选改造方向；当前没有实施首页 SSR 或容量改造，也没有新的性能、SEO 或十万并发验证结果。
第二条已补充 Axios 公共请求层与 TanStack Query 的协作，见本页“2026-10-22 第二条补充 Axios 与 TanStack Query 分工”。请求传输、查询管理及端侧会话处理各有职责；后续不因技术名在第一条出现过就省略案例所需的实现依托，也不因此扩写通用工具教程。
第三条“SKU 规格联动”当前以 2026-10-23“同日补充规格选择与选购联动（当前采用）”为准：保留来源兼容删除决定，补清任意顺序选择与反选、规格图片/SKU 价格/数量范围联动及切换后的数量校正，算法与购买前校验继续保留。折扣展示、三端图片位置、库存缺失及低于起购量的边界见该节；本地状态分离和刷新在途复用、旧提示隔离只作面试素材，不写刷新保留选择或全部异步回调隔离。本人关于后端可能统一 propId 的回忆尚未核验，不由兼容分支推定适配经历或公司代码已清理，也不将前端校验扩大为后端库存保证。
第四条“结算与支付流程”当前以“2026-10-29 第三至第五条的技术方法与简述平衡（当前采用）”为准：正文保留按结算标识组织 Query Key、隔离预览缓存与定向清理，并继续简述 Web/RN 支付接入、服务端金额及按钮限制、回跳与有限轮询、上限后手动重查和数据刷新。字段、完整缓存键及逐项有效预览判断留在 2026-10-22 详述中；不把常规缓存组织说成算法创新，也不恢复同步提交锁。创建订单不等于支付成功，退出不等于取消后端订单，重查不等于重新支付；移除 submittingRef 的计划未确认完成，不扩大后端资金或账务成果。
第五条“三端客服聊天”当前以同节“技术方法与简述平衡”为准：保留 WebSocket、消息合并去重、本地回显、ACK 确认及超时同客户端 ID 重发与后端幂等配合，咨询切换和重连补拉继续概括；两种 ID 的完整分工、请求序号、图片回调、消息类型清单及具体重连方式留在上下文。不要将必要方法一并删成纯功能概述，也不恢复全套协议步骤。正文仍按本人指定的新方案完成式，实际代码未按新方案优化，后端约定及验证仍待完成；四项可靠性问题不标为已修复，不新增个人贡献、测试、上线或收益结论。
第六条“RN 兼容与稳定性”当前以“2026-10-30 第六条整条精简（当前采用）”为准：安全区与键盘适配收为按实测底栏高度配置键盘避让，保留启动日志、Hermes 与运行时/编译配置对齐；子区域横滑协调并入移除原生分页器、仅渲染当前页及横滑切换的方案。完整工具名与参数留在前一阶段及当前节的实现入口中，不因正文省略而重新逐项堆回。双端指 iOS / Android，当前页指激活标签内容；现有代码、静态分析、文档诊断和待完成 Release / 灰度验证继续区分，不新增唯一根因、崩溃消除或全设备结论，也不沿用第五条的新方案假设。
第七条“线上问题排查”当前以“2026-10-31 第七条精简与 RN 表单线上排查确认（当前采用）”为准：保留 DOM 异常线索与 Chrome 翻译故障；RN 部分按表单重置、前台恢复时鉴权刷新导致卸载重建、守卫修复组织，后台校验期间保持表单挂载及输入状态。本人已明确确认该表单问题在线上发现后由本人排查定位，不再将线上来源和个人排查列为待确认。具体设备、密码服务、调试步骤、实现与回归分工和验证范围仍待补；修复前已存在首次加载/后台查询的状态区分，不写成关闭鉴权刷新。仓库状态残留及 H5 支付跳转只作面试素材，历史记录保留；翻译采集链、开发环境限制及其他监听的待回忆边界也保留，不新增完整监控、全部环境覆盖或收益。
第八条“测试与构建发布”当前以“2026-10-31 第八条结构调整与 PM2 处理方法（当前采用）”为准：按测试、Web 发布、RN 发布组织，保留代表性单测规则、PC/H5 Playwright、云效、standalone 版本目录与软链接切换、健康检查与失败回退，补出重建测试环境 PM2 进程定义的修法；EAS 构建、Android/iOS 双端提审及 OTA 兼容范围和原生变更重打包继续保留。完整来源与测试分层、未核实的自动测试门禁、HTTP 检查局限、PM2 首次接管、App version 运行时策略、商店人工审核及 OTA 待办见 2026-10-22 来源节，不据新文案新增测试通过、完整覆盖、零停机或灰度演练完成结论。
Android 三键/手势导航切换后的顶部黑条仅作为面试素材，见本页“2026-10-31 Android 导航模式切换后顶部黑条”。按 7 月 27 日系统栏适配、28 日启动背景/Splash 时机、29 日窗口恢复与原生生命周期同步的演进回顾；旧 Plugin 已随 SDK 56 升级移除，新包专项回归仍待补。第七条仍为 Chrome 翻译与 RN 密码回填两例，不因保存素材新增个人分工、全机型或线上恢复结果。
第二个“BBD 跨境电商运营管理后台”当前以“2026-11-07 运营后台按业务组件与交互重组（当前采用）”为准。简介沿用已确认的业务范围，职责概括业务页面、业务组件定制与复用和工程优化；六条依次为后台工程组织与公共能力、订单分层展示与采购物流编辑、仓储分箱与条码作业、售后表单与批量处理、仓储绩效与目标展示、登录依赖与发布检查。第一条保持短版，第二至第四条突出回填、编辑值同步、跨行校验、分配状态及渠道规则。订单嵌套展示已并入第二条，客服与财务导出移作候选，优惠券和商品 SKU 编辑也留作备选；技术栈保留实际使用的工具。实现依据、个人来源和未验证边界见该节及技能项目对照，不将项目实现、改稿授权或组件定制扩大为逐项独立设计、完整组件库、后端权限与资金处理或量化收益。

2026-10-10 根据新版简历制定面试复习计划，是此前本人确认的事项；本次没有提前替本人完成或确认该计划，也没有新增投递、面试或任务完成记录。

关联阅读

张育华的求职简历：React 与 React Native 多端开发、公共请求治理和跨境电商项目经验。
简历技能与项目对照：技术能力与项目案例的对应关系、确认范围和后续补充入口。
职业经历与 BBDbuy：从 2022 年开始的工作经历，以及借助 Codex 推进三端项目的实践。
2026-09 简历存档：保留 2026-09-11 提供的 PDF 简历原文；其中工作时间已由本人说明不实，不能作为真实经历依据。