Lammps建模金刚石+GaN出现报错：ERROR: Atom count is inconsistent, cannot write data file (../write_data...如何解决？

🏆本文收录于 《全栈 Bug 调优（实战版）》 专栏。专栏聚焦真实项目中的各类疑难 Bug，从成因剖析 → 排查路径 → 解决方案 → 预防优化全链路拆解，形成一套可复用、可沉淀的实战知识体系。无论你是初入职场的开发者，还是负责复杂项目的资深工程师，都可以在这里构建一套属于自己的「问题诊断与性能调优」方法论，助你稳步进阶、放大技术价值。

📌特别说明：
文中问题案例来源于真实生产环境与公开技术社区，并结合多位一线资深工程师与架构师的长期实践经验，经过人工筛选与AI系统化智能整理后输出。文中的解决方案并非唯一“标准答案”，而是兼顾可行性、可复现性与思路启发性的实践参考，供你在实际项目中灵活运用与演进。

欢迎订阅本专栏，一次订阅后，专栏内所有文章可永久免费阅读，后续更新内容皆不用再次订阅，持续更新中。

📢 问题描述

详细问题描述如下：

Lammps建模金刚石+GaN出现报错无法解决：lammps中将GaN和Diamond两种模型导入同一个模型后输出出现以下几种报错
我想做一个堆叠的模型，GaN在上，Diamond在下，势函数使用的混合（Tersoff+LJ）使用了两种方法，分别是：

方法一：导入GaN后将其移动到上部，然后在下面进行建模Diamond，

出现过的错误如下：
1、Atom lost
2、ERROR: Atom count is inconsistent, cannot write data file (…/write_data.cpp:150)

方法二：导入GaN后将其移动到上部，然后在下面进行add append命令导入Diamond

出现过的错误如下：

1、ERROR: Atom count is inconsistent, cannot write data file (…/write_data.cpp:150)
2、ERROR: Numeric index 3 is out of bounds (1-2) (…/input.cpp:1561)

请问这样的错误该如何解决呢？或者说我的两种方法哪一种修改后更适合解决这个问题？

📣 请知悉：如下方案不保证一定适配你的问题！

如下是针对上述问题进行专业角度剖析答疑，不喜勿喷，仅供参考：

✅️问题理解

我先直接给结论：你现在更适合走“方法二的改造版”，也就是用两次read_data把 GaN 和 Diamond 合并到一个系统里，而不是“先读 GaN，再移动，再在下面现场建 Diamond”的原始方法一。🙂

你现在遇到的 3 类报错，其实大概率不是 3 个独立问题，而是同一套建模流程里 3 个环节同时有坑：

1. 类型数（atom types）没预留够
2. 两块材料在空间上重叠或被移出盒子
3. 混合势hybrid/hybrid+Tersoff+LJ的定义方式不规范

这三件事会连锁触发你看到的报错。

先逐个翻译成“人话”：

1）ERROR: Numeric index 3 is out of bounds (1-2)

这个报错在 LAMMPS 官方文档里的意思非常明确：你在某条命令里引用了编号 3，但系统当前只允许 1~2。这最常见于pair_coeff、mass、set type、create_atoms、read_data offset这些和“类型编号”相关的命令。官方也明确说了：这个错误通常就是输入里编号越界，或者定义顺序/逻辑有问题。

结合你的场景，这个错误几乎可以直接定位为：

• 你先读入了GaN，如果它的数据文件里只有2 个 atom types（例如 1=Ga，2=N）；
• 然后你又想再加入Diamond，它应该需要一个新的类型，比如3=C；
• 但如果第一次read_data时没有用extra/atom/types 1预留额外类型，那么系统的 atom types 上限就被锁死在 2 了；
• 这时你再写type 3、mass 3、pair_coeff 1 3 ...、或者第二次read_data ... offset 2 ...，就会立刻炸成这个错误。官方文档明确说明：第一次read_data之后，类型上限就锁定了；后续再读文件要么提前预留 extra types，要么一开始就用create_box把总类型数建好。

2）Atom lost

这个报错不是“LAMMPS 算坏了”，而是 LAMMPS 在告诉你：有原子在积分过程中飞没了 / 被删了 / 逃出当前处理范围了。官方说明里写得很直接：lost atoms 通常意味着坏动力学，最常见原因是：

• 原子靠得太近，初始重叠，受力爆炸；
• 时间步太大，原子一个时间步飞太远；
• 盒子尺寸/边界在开始时变化过大；
• 非周期固定边界下，原子出了盒子就会被删掉；
• shrink-wrap 边界在并行时突然收缩，也可能导致刚开始就丢原子。

放到你的场景里，这个报错最可能来自两种情况：

情况 A：GaN 和 Diamond 有几何重叠

• 你把 GaN 移到上面，再在下面建 Diamond，但“下面”的 region 和 GaN 底部可能实际上有交叠；
• 或者第二次read_data add append加进来的 Diamond 通过shift后仍和 GaN 有部分原子距离过小；
• 这会让 Tersoff/LJ 作用下初始力非常大，第一步或前几步就把原子打飞。官方也建议这种情况要先去除 close contacts，典型手段就是delete_atoms overlap，并且先做最小化、减小 timestep，必要时临时用fix nve/limit或fix dt/reset。

情况 B：你把 GaN 移出当前盒子了

• 如果你先读入 GaN，然后直接displace_atoms往 z 正方向挪，但是盒子上边界没有先change_box扩出去；
• 且 z 方向用的是固定非周期边界f；
• 那么原子一旦被挪到盒子外，下次重建邻居时就会被删除，官方明确写了：fixed 边界下原子出盒子会被删掉。

3）ERROR: Atom count is inconsistent, cannot write data file

这个错误官方解释也非常直接：各处理器统计到的原子总数和全局记录的总数不一致，通常说明你之前已经丢原子了。换句话说，这往往不是“write_data本身的问题”，而是前面已经出事了，只是到write_data这里才被彻底检查出来。

所以这条报错在你的案例里，通常不是根因，而是前面Atom lost的结果。

4）你这两种建模方法，本质差异是什么？

你现在的两种方法本质上是：

• 方法一：先读入 GaN，再移动，然后用脚本现场创建 Diamond
• 方法二：先读入 GaN，再移动，然后通过read_data add append再导入 Diamond

从可控性来看：

• 方法一更容易在盒子尺寸、类型编号、region、lattice、create_atoms 的几何边界上出问题
• 方法二更适合“两个已有晶体结构文件做堆叠拼接”

尤其官方read_data文档已经把多数据文件拼接的机制讲得很清楚了：
后续读入数据时要配合add append、offset、shift、group，并且第一次读取时要用extra/atom/types预留后续新增类型。

所以我对你这个问题的判断是：

你不是遇到一个 bug，而是遇到了“类型编号 + 空间拼接 + hybrid 势设置”三个典型坑叠加。

✅️问题解决方案

🟢方案 A：推荐方案——改造你的“方法二”，采用“双read_data+offset+shift+group+ 明确定义 hybrid 势”

这是我最推荐的方案。原因很简单：

• 对已有 GaN / Diamond 结构文件最友好；
• 原子 ID、类型 ID、空间位置都能精确控制；
• 最适合定位你现在这类错误；
• 也最符合 LAMMPS 官方对多数据文件拼接的使用方式。

A-1. 核心原则

如果你的体系是：

• GaN：2 个类型（假设 1=Ga, 2=N）
• Diamond：1 个类型（原始文件里通常也是 type 1，但导入后应变成全局 type 3=C）

那么正确做法是：

1. 第一次读入 GaN 时，预留 1 个额外 atom type
2. 第二次读入 Diamond 时，使用
   add append解决原子 ID 追加
3. 再用
   offset 2 0 0 0 0
   让 Diamond 文件内部原本的type 1变成全局type 3
4. 用shift直接在读入时把 Diamond 放到下方，不要先读进来再乱挪
5. 两份 data 文件尽量用nocoeff读入，把所有势函数定义放在主输入脚本里，避免 hybrid 势从 data 文件里读 coeff 的各种歧义；官方明确说了：hybrid 风格不推荐通过 data 文件中的 Pair Coeffs / PairIJ Coeffs 来读。

A-2. 你这个场景里最稳的脚本骨架

下面给你一个可以直接照着改的结构化模板。
我这里不乱填 LJ 参数，因为Ga-C / N-C 的 epsilon、sigma 必须依据你的文献来源或标定方案来定，这部分我只给占位符，避免误导你。

下面假设：

• GaN 文件内部类型：1=Ga, 2=N
• Diamond 文件内部类型：1=C
• 最终全局类型：1=Ga, 2=N, 3=C

units metal dimension 3 boundary p p f atom_style atomic # ---- 读入 GaN，预留 Diamond 的 1 个新类型 ---------- read_data GaN.data extra/atom/types 1 group gan nocoeff # ---------- 可选：先检查一下 ---------- thermo 1 run 0 # ---------- 导入 Diamond 到下方 ---------- # offset 2 -> Diamond 文件内的 type 1 变成全局 type 3 # shift 的 z 值按你的几何尺寸调整 read_data Diamond.data add append offset 2 0 0 0 0 shift 0.0 0.0 -DZ group dia nocoeff # ---------- 质量 ---------- mass 1 69.723 mass 2 14.007 mass 3 12.011 # ---------- 势函数 ---------- # 注意：这里用 hybrid，不是 hybrid/overlay pair_style hybrid tersoff tersoff lj/cut 10.0 # GaN 内部：type 1,2；type 3 为空 pair_coeff * * tersoff 1 GaN.tersoff Ga N NULL # Diamond 内部：只有 type 3=C；type 1,2 为空 pair_coeff * * tersoff 2 C.tersoff NULL NULL C # 跨界面相互作用：Ga-C, N-C 只用 LJ pair_coeff 1 3 lj/cut EPS_GaC SIGMA_GaC 10.0 pair_coeff 2 3 lj/cut EPS_NC SIGMA_NC 10.0 neighbor 2.0 bin neigh_modify every 1 delay 0 check yes # ---------- 删除重叠原子（非常关键） ---------- delete_atoms overlap 0.5 dia gan # ---------- 导出调试轨迹 ---------- dump d0 all custom 1 debug_merge.lammpstrj id type x y z run 0 # ---------- 初始最小化 ---------- min_style fire minimize 1.0e-12 1.0e-12 10000 100000 # ---------- 小步长预热，避免 lost atoms ---------- timestep 0.0001 fix f1 all nve/limit 0.02 run 1000 unfix f1 # ---------- 正常时间步 ---------- timestep 0.001

A-3. 这里为什么必须用hybrid，而不是hybrid/overlay？

这是个很关键但很容易写错的点。

你的目标是：

• GaN 内部：用 Tersoff
• Diamond 内部：用 Tersoff
• GaN–Diamond 跨界面：只用 LJ

这种需求应该用pair_style hybrid，因为官方明确说明：
在hybrid里，每个原子类型对I,J只归属于一个子势；如果你又给同一对原子重复指定另一个子势，就会覆盖或逻辑混乱。

而hybrid/overlay的含义是：同一对原子可以叠加多个势。
这通常不适合你这个场景，因为你并不想让C-C同时吃到 Tersoff 和 LJ，也不想让Ga-N同时吃到 Tersoff 和 LJ。

所以这里：

• 用hybrid
• 不要乱用overlay

A-4. 为什么你现在的Numeric index 3在这个方案里会消失？

因为它的根因是：系统只认 1~2 类型，但你后续用了 3。

这个方案里，第一次读入 GaN 时已经：

read_data GaN.data extra/atom/types 1

官方说得很清楚：
第一次read_data后类型上限就锁定；如果你要后续再加新材料、新类型，就必须第一次就预留extra/atom/types。

所以当第二次读入 Diamond 时：

read_data Diamond.data add append offset 2 0 0 0 0

其原本的type 1会安全变成type 3，不会再越界。

A-5. 为什么Atom lost在这个方案里也更容易控制？

因为这个方案同时处理了 3 个最关键点：

（1）导入时直接 shift，而不是读完再乱挪
这样不容易把一部分原子挪出盒子。read_data的shift官方就是给这种“多结构拼装”准备的。

（2）先删重叠，再最小化
官方明确建议 close contacts 可以用delete_atoms overlap去掉，然后先最小化，再小步长预热。

（3）一开始用很小时间步或fix nve/limit
官方也明确说了：初始化阶段如果运动太剧烈，可临时用fix nve/limit或fix dt/reset限制位移，避免 lost atoms。

A-6.delete_atoms overlap该怎么设？

这个命令非常有用，但别机械地抄数值。

原则是：

• cutoff 要大于“明显重叠”的距离
• 但不能大到把正常界面层也删坏了

比如你可以先从：

delete_atoms overlap 0.3 dia gan

或

delete_atoms overlap 0.5 dia gan

开始试。
官方说明也提到：这个命令依赖邻居表，所以需要先把 pair style / masses / neighbor 等准备好，而且 overlap cutoff 不能超过当前可构建的邻居范围。

我的经验建议是：

• 如果你是直接晶格对接，先试0.2~0.5 Å

• 如果是非常紧贴的界面，可以逐步扫描：

  • 0.2
  • 0.3
  • 0.4
  • 0.5

每次run 0+ 看dump，找不重叠又不误删的阈值。

A-7.write_data这里还要特别注意一个坑

就算你把系统拼好了，write_data也不是 hybrid 势的完美保存方式。

LAMMPS 官方明确说了：

• write_data对 hybrid 势未必能完整写出 coeff 信息；
• hybrid 风格下，很多 coeff 信息不会完整保存在 data 文件里；
• 尤其i != j的交叉 pair coeff，如果只写普通Pair Coeffs，会丢失。

所以这里我的建议是：

如果你只是想保存几何结构：

write_data merged_geom.data nocoeff

如果你想以后完整续算：

write_restart merged.restart

然后以后读入时：

• read_data只负责几何
• pair_style / pair_coeff放在独立输入脚本里
• 或直接read_restart

这会稳定很多。

🟡方案 B：保留你的“方法一”，但必须改造成“先扩盒，再移动，再创建 Diamond”，否则非常容易继续炸

这个方案可以做，但不如方案 A 稳。
我只把它作为“如果你必须现场生成 Diamond 晶格”的备选方案。

B-1. 这个方法为什么原来容易错？

因为它通常会犯下面这些错误：

1. GaN 还没扩盒就先上移

   • 一部分原子被移出zhi
   • 如果 z 是 fixed 边界f，这些原子后面会被删掉 →Atom lost/Atom count inconsistent。

2. 系统只有 2 个类型，却想create_atoms 3

   • 直接触发Numeric index 3 is out of bounds (1-2)。

3. 新建 Diamond 的 region 和 GaN 底部仍有穿插

   • 首步爆力 → lost atoms。

B-2. 如果你一定要用方法一，正确顺序应该是这样

units metal dimension 3 boundary p p f atom_style atomic # 先读 GaN，同时预留 Diamond 的类型 read_data GaN.data extra/atom/types 1 group gan nocoeff # 先把盒子 z 方向扩出来，再移动 GaN change_box all z final ZLO_NEW ZHI_NEW remap units box displace_atoms gan move 0.0 0.0 DZ units box # 这里再定义 Diamond 晶格并创建 type 3 lattice diamond 3.567 region diareg block INF INF INF INF Z1 Z2 units box create_atoms 3 region diareg mass 1 69.723 mass 2 14.007 mass 3 12.011

这套顺序里，最关键的是：

• 先change_box再displace_atoms

• 第一次读数据就预留 type 3

• Diamond region 必须和 GaN 底部留出合理初始间隙

• 之后仍然要做：

  • delete_atoms overlap
  • minimize
  • 小步长预热

B-3. 这个方案什么时候适合？

适合这些情况：

• 你的 Diamond 不依赖一个已有的 data 文件，而是想用 LAMMPS 内部lattice diamond + create_atoms直接生成
• 你想程序化控制 Diamond 的尺寸、切割区域、晶向

但如果你已经有可靠的 Diamond data 文件，那我仍然建议别折腾这个方案，直接回到方案 A。

🔴方案 C：在外部工具里先把两个结构合并好，再让 LAMMPS 只做计算

这个方案不一定比方案 A 更优，但在某些情况下更省心：

• 你用 OVITO / VMD / Atomsk / Materials Studio / Python ASE 先把两个晶体拼好；
• 在外部检查界面间距、删重叠、统一类型编号；
• 最后导出一个干净的单一 data 文件给 LAMMPS。

这个方案的优点：

• 可视化拼接最直观
• 几何问题最容易发现
• 不容易在 LAMMPS 输入脚本里把 box / shift / type offset 写乱

缺点是：

• 外部前处理多一步
• 如果你后面要批量扫描界面距离、旋转角度，就没有脚本自动化方便

如果你只是要先把这一个模型跑通，这个方案其实非常稳。

✅️问题延伸

这里有几个你现在必须知道的“更深一层”的问题，否则就算模型跑起来，也可能结果不物理。

1）Tersoff + LJ在 GaN/Diamond 界面上是否物理合理？

这要分目标。

如果你的目标是：

• 做一个机械接触/层状堆叠模型；
• 关心几何接触、初步热输运趋势；
• 假定界面主要是弱相互作用，不发生明显成键重构；

那么：

• GaN 内部用 Tersoff
• Diamond 内部用 Tersoff
• 跨界面用 LJ

这是一个常见的工程化近似，能跑，也容易控。

但如果你的目标是：

• 研究界面真实成键；
• 研究界面化学反应、重构、缺陷诱导键合；
• 研究非常依赖界面三体效应/电荷转移的现象；

那么这个混合方案就有明显局限，因为在hybrid里，每一对类型只归属于一个子势，跨材料那部分如果只给 LJ，就不会自动拥有 Ga-N-C 跨界面的多体成键项。LAMMPS 官方关于 hybrid 和 many-body 势的说明也暗示了这种映射/分配必须非常谨慎。

所以你要先明确：

• 你做的是弱耦合界面模型
• 还是真实界面化学模型

这两者的势函数策略差别很大。

2）add append只管原子 ID，不管 atom type 逻辑

这是很多人第一次拼系统最容易误解的点。

官方read_data明确写了：

• append：负责把新文件的 atom ID 接到当前系统后面；
• offset：负责把新文件里的类型编号整体偏移。

也就是说：

read_data Diamond.data add append

只解决“ID 冲突”；

但如果你还要把 Diamond 的内部type 1变成全局type 3，必须再加：

offset 2 0 0 0 0

这个逻辑你以后做任何多相材料拼接都要记住。

3）write_data不适合当 hybrid 势的“完整存档格式”

这个坑你以后还会反复遇到。

官方已经明确提醒：

• hybrid 情况下，write_data未必能完整保存 coeff；
• 有的势本来就不适合写回 data 文件；
• 想完整重启更推荐 restart。

所以以后你最好养成习惯：

• 结构文件和势函数定义文件分开管理
• 或直接用write_restart

4）不要用thermo_modify lost ignore来“掩盖问题”

官方对此写得很明确：
除非你的物理过程本来就允许原子离开系统（比如蒸发、溅射），否则lost ignore只是把问题藏起来，不是解决问题。

所以你的情况里：

• 不要靠 ignore 混过去
• 先把几何和势函数定义修正干净

✅️问题预测

如果你按上面方案修完，下一批很可能会遇到的错误/隐患，我提前帮你列出来：

预测 1：All pair coeffs are not set

如果你定义了 3 个类型：

• 1=Ga
• 2=N
• 3=C

那你至少要保证这些对都被覆盖到：

• 1-1, 1-2, 2-2 → GaN Tersoff
• 3-3 → C Tersoff
• 1-3, 2-3 → LJ

只要漏一个，就可能报 pair coeff 未设完整。
官方 hybrid 说明里也强调：每个类型对都要被分配到一个子势。

预测 2：Incorrect args for pair coefficients

这通常发生在：

• pair_coeff * * tersoff ...后面的元素映射个数不对；
• 映射顺序和 atom types 对不上；
• 你系统里明明 3 个 types，却只写了 2 个映射名；
• 或者把NULL位置写错。
  官方 Tersoff 文档明确说了：pair_coeff * * tersoff file后必须跟N 个映射项，N 就是系统总 atom types 数；hybrid 情况下可用NULL给不属于该子势的类型占位。

预测 3：最小化阶段不炸，但一开始 MD 还是Atom lost

这说明你虽然删掉了最明显的重叠，但仍可能存在：

• 初始界面距离太小
• 时间步偏大
• LJ 参数过硬
• 边界/盒子尺寸不合适

这种情况下按官方建议继续做：

• 更小 timestep
• 更长一点的最小化
• 临时fix nve/limit
• 检查是否有原子在 z 边界附近被挤出去。

预测 4：重新读取你写出的 data 文件时势函数不对

这往往不是你“保存坏了几何”，而是hybrid coeff 没完整写回去。
这时别怀疑人生，先看是不是用了write_data试图完整保存 hybrid 势。官方已经提醒过这一点。

预测 5：并行时比串行更容易一开始就掉原子

官方对 shrink-wrap 和域分解引起的 lost atoms 也有说明。
所以你在调试阶段最好先：

• 用1 核 / 串行
• thermo 1
• dump 1
• run 0
• 再最小化
• 再短跑 100~1000 步

等模型稳了，再上并行。

✅️小结

我把最终判断给你浓缩成一句话：

你最适合采用“方法二的改造版”，即：第一次read_data预留新类型，第二次read_data add append offset shift导入另一块材料，再用hybrid明确分配 Tersoff/LJ，随后做delete_atoms overlap + minimize + 小步长预热。

你这几个报错的对应关系，可以这样记：

• Numeric index 3 is out of bounds (1-2)
  = 你在用type 3，但系统只建立了1~2 类型
  → 根治：第一次read_data加extra/atom/types

• Atom lost
  = 原子重叠、飞出盒子、时间步太大、边界不合适
  → 根治：shift合理放置、删重叠、最小化、小步长

• Atom count is inconsistent, cannot write data file
  = 通常不是write_data根因，而是前面已经丢原子了
  → 根治：先把 lost atoms 解决掉

最后给你一个最实用的执行顺序，你照着做，通常就能跑通：

1. 先确定全局类型编号：1=Ga, 2=N, 3=C
2. 第一次读 GaN：read_data GaN.data extra/atom/types 1 group gan nocoeff
3. 第二次读 Diamond：read_data Diamond.data add append offset 2 0 0 0 0 shift ... group dia nocoeff
4. 用pair_style hybrid，不要乱用hybrid/overlay
5. 给两套 Tersoff 分别做NULL映射
6. 只给1-3、2-3定义 LJ
7. delete_atoms overlap
8. run 0+ 看 dump
9. minimize
10. 小步长 +fix nve/limit
11. 稳定后再正常 MD

最后我想确认一个关键点：你的 GaN data 文件是不是只有 2 个 atom types，而 Diamond data 文件只有 1 个 atom type？
如果是，那你的Numeric index 3 is out of bounds (1-2)我基本可以确定就是“第一次没有预留 extra/atom/types，第二次又想引入 type 3”这一条导致的。🙂

如果你把你现在的这几段脚本贴出来——尤其是：

• read_data
• displace_atoms
• change_box
• pair_style
• pair_coeff
• boundary
• write_data

我可以下一条直接帮你逐行改成可运行版本。

🌹 结语 & 互动说明

希望以上分析与解决思路，能为你当前的问题提供一些有效线索或直接可用的操作路径。

若你按文中步骤执行后仍未解决：

• 不必焦虑或抱怨，这很常见——复杂问题往往由多重因素叠加引起；
• 欢迎你将最新报错信息、关键代码片段、环境说明等补充到评论区；
• 我会在力所能及的范围内，结合大家的反馈一起帮你继续定位 👀

💡如果你有更优或更通用的解法：

• 非常欢迎在评论区分享你的实践经验或改进方案；
• 你的这份补充，可能正好帮到更多正在被类似问题困扰的同学；
• 正所谓「赠人玫瑰，手有余香」，也算是为技术社区持续注入正向循环

🧧 文末福利：技术成长加速包 🧧

文中部分问题来自本人项目实践，部分来自读者反馈与公开社区案例，也有少量经由全网社区与智能问答平台整理而来。

若你尝试后仍没完全解决问题，还请多一点理解、少一点苛责——技术问题本就复杂多变，没有任何人能给出对所有场景都 100% 套用的方案。

如果你已经找到更适合自己项目现场的做法，非常建议你沉淀成文档或教程，这不仅是对他人的帮助，更是对自己认知的再升级。

如果你还在持续查 Bug、找方案，可以顺便逛逛我专门整理的 Bug 专栏👉《全栈 Bug 调优（实战版）》👈️

这里收录的都是在真实场景中踩过的坑，希望能帮你少走弯路，节省更多宝贵时间。

✍️如果这篇文章对你有一点点帮助：

• 欢迎给 bug菌 来个一键三连：关注 + 点赞 + 收藏
• 你的支持，是我持续输出高质量实战内容的最大动力。

同时也欢迎关注我的硬核公众号 「猿圈奇妙屋」：

获取第一时间更新的技术干货、BAT 等互联网公司最新面试真题、4000G+ 技术 PDF 电子书、简历 / PPT 模板、技术文章 Markdown 模板等资料，通通免费领取。
你能想到的绝大部分学习资料，我都尽量帮你准备齐全，剩下的只需要你愿意迈出那一步来拿。

🫵 Who am I?

我是 bug菌：

• 热活跃于 CSDN | 掘金 | InfoQ | 51CTO | 华为云 | 阿里云 | 腾讯云 等技术社区；
• CSDN 博客之星 Top30、华为云多年度十佳博主/卓越贡献者、掘金多年度人气作者 Top40；
• 掘金、InfoQ、51CTO 等平台签约及优质作者；
• 全网粉丝累计30w+。

更多高质量技术内容及成长资料，可查看这个合集入口 👉 点击查看 👈️

硬核技术公众号「猿圈奇妙屋」期待你的加入，一起进阶、一起打怪升级。

- End -