git操作和数据结构使用

考点一：Git 分支操作（工程化协作能力）

面试官问这个，不是考你命令拼写，而是看你在多人协作、版本发布、紧急热修复场景下有没有成熟的工程规范。

1. 基础认知（常用命令与场景）

• 分支管理：
  • git branch（查看）/ git checkout -b feat/xxx（新建并切换）/ git branch -d（删除）。
  • git merge（合并） vs git rebase（变基）：merge 保留完整历史（有分叉），rebase 让历史呈线性（更干净，但不要在公共分支上对已推送的提交做 rebase）。
• 协作流程：
  • git fetch（拉取远端更新，不合并） vs git pull（fetch + merge）。
  • git push --force-with-lease（强制推送的“安全版”，会检查远端是否有人先推送了，避免覆盖同事代码）。

2. 进阶原理（解决冲突与 Git Flow 规范）

• 冲突解决：当两个分支改了同一文件同一行，git status 看冲突文件，手动编辑删除 <<<<<<< HEAD 标记，然后 git add + git commit。
• Git Flow（经典工作流）：master（生产） + develop（开发主分支） + feature/*（新功能） + release/*（发布前预演） + hotfix/*（紧急线上修复）。热修复流程：从 master 拉 hotfix/* -> 修复 -> 合并回 master 并 同步合并回 develop（很多人会忘这一步！）。

3. 结合你的简历（华为 WeLink 和 海嵘 实战）

“在华为软通（WeLink），由于团队规模大（前端30+人），我们严格遵循 Git Flow。我在开发消息模块时，从 develop 拉取 feature/wechat-message 分支开发，每天上班第一件事是 git pull origin develop --rebase，把主分支的最新提交‘变基’到我本地，避免后期出现‘合并地狱’。上线前发起 MR（Merge Request），必须通过 CI（持续集成）流水线且 2位核心成员 Approve 才能合入 develop。

在海嵘（小团队），流程简化，但我在一次线上紧急修复（PDF报告生成乱码）时，严格按 hotfix 流程走：从 master 拉分支 -> 修复 -> 合并回 master 并打 v1.2.1 标签，同时手动 Cherry-pick 到 develop，确保下次发版不会丢失这个修复。”

考点三：项目用到了哪些数据结构？怎么用的？（考察工程中算法的落地）

面试官问这个，是想确认你不仅仅会写 for 循环，还能根据业务场景选择合适的数据结构来优化性能（时间复杂度）。

1. 基础认知（JS 内置数据结构回顾）

• 数组（Array）：有序列表，适合随机访问（O(1)），但插入/删除中间元素慢（O(n)）。
• 对象（Object）/ 映射（Map）：键值对，适合快速查找（O(1)）。Map 优于 Object 的地方在于：Key 可以是任意类型（包括对象）、且有序、大小直接 size 获取。
• 集合（Set）：天然去重，适合做“存在性”判断。
• 栈（Stack）：后进先出（LIFO），push + pop。
• 队列（Queue）：先进先出（FIFO），push + shift（或双指针）。
• 树（Tree）：层级结构，如 DOM 树、路由树。

2. 进阶原理（时间复杂度分析与选择依据）

“数组的 unshift / shift 时间复杂度是 O(n)（因为要移动所有索引），在数据量大的队列场景，我会用**双指针（Head 指针）**代替 shift。查找高频操作用 Map（哈希表 O(1)），避免用 Array.find（O(n)）。”

3. 结合你的简历（4个具体场景，超级硬核）

• 场景一（WeLink 消息列表 —— 数组 + 虚拟滚动）：

  “消息列表用数组存储，配合 react-window 的虚拟滚动。当新消息涌入时，我用 ... 浅拷贝生成新数组入队。为了去重（防止重复推送同一条消息），我维护一个 Set（消息ID集合），每次入队前查 Set，保证消息唯一性。”

• 场景二（MMMP 告警队列 —— 优先级队列/链表）：

  “设备异常告警分‘紧急’‘警告’‘普通’三级。我不直接处理，而是将告警放入一个优先级队列（底层用链表实现）。紧急告警插入链表头部，普通告警插入尾部。主线程空闲时（requestIdleCallback）从头部取出一条处理，保证紧急告警秒级响应。”

• 场景三（IAMP 隧道点云 —— 四叉树/空间索引）：

  “百万个点云坐标（X,Y,Z），要做区域裁剪或视锥体裁剪时，我用了 Octree（八叉树） 算法（Three.js 内置 Octree 类）。它将三维空间递归分成 8 个象限，鼠标点击时，只需遍历命中象限的子树，将原本 O(n) 的遍历降为 O(log n)，点击拾取延迟从 200ms 降到 5ms 以内。”

• 场景四（IRMP 报告动态表单 —— 树形结构遍历）：

  “隧道检测报告有复杂的嵌套结构（章节 -> 小节 -> 表格 -> 图片）。我用**树（Tree）**存储这份 JSON Schema。用户填写时，我实现了一个 walkTree 递归函数（深度优先遍历），自动收集所有叶子节点的值用于生成 PDF。同时用 栈（Stack） 控制面包屑导航（用户点击下一级，push 当前节点；点击返回，pop 弹出）。”

面试现场组合技（必杀话术）

如果面试官连续问这三个问题，你最后可以用一段话把三者串起来，展现你的综合架构能力：

“（指着简历上的 IAMP 项目）我们当时在处理点云数据时，为了深拷贝问题吃了大亏——直接用 JSON.parse(JSON.stringify(pointData)) 导致页面直接卡死。后来我改用结构化克隆算法配合 Transferable 转移所有权给 Worker。

在版本管理上，因为这块核心代码涉及底层算法优化，我们没有直接合并到 develop，而是切了一个 feature/octree-optimize 分支单独验证。验证达标后，通过 Git Rebase 保持提交历史线性干净，再合入主分支。

正是因为引入了 Octree（八叉树）数据结构，我们成功把点击拾取的复杂度从 O(n) 降到了 O(log n)，用户交互体验飞升。可见数据结构选对了，优化效果比单纯堆砌代码好十倍。”

把这 4 个场景（Set去重、链表队列、树形遍历、八叉树）记住，Git 讲清楚 rebase 和 hotfix 细节，拷贝强调 structuredClone 和性能陷阱。