文章来源：GTHN中文维基
✅ 尽量
尽量倍增配方： 将
1铁锭 < 1铁粉改为64铁锭 < 64铁粉，把 64 次计算查询降为 1 次。尽量保证样板中无消耗耐久的工具： 工具耐久计算会拖垮 TPS。请使用组装机或一次性扳手，不要用真正的工具。
尽量在大量 I/O 时创建子网： 将数据交互限制在子网内，主网只接收最终成品，确保主网响应其他请求。
尽量安排无需物品转移的生产方式： 物品在网络中转移会消耗性能。
尽量使用 AE 存储元件： 存在元件里的物品哈希已预计算，查询极快（超级箱/罐/量子缸也有特殊优化，推荐使用）。
尽量合并存储： 使用元件工作台给存储元件标记物品，并设置驱动器优先级，避免同种物品散落在多个元件中，减少计算延迟。
尽量无线连接 ME 网络： 替代超长实体线缆，降低客户端渲染压力和网络更新延迟。
尽量使用 P2P： 替代满频道线缆，有效梳理网络结构且耗能更低。
尽量使用无线连接器（同维度下）： 替代量子环，虽然耗电但延迟更低。
🚫 避免
避免超级递归子网络：不要把存储放在“子-子-子-子-子网”里，每次访问都会引发嵌套计算。
避免大量使用请求器（库存维持）： 频繁让 AE2 计算复杂的配方树会榨干 CPU。
对策：增加下单间隔/数量，缩短配方树。凡是大量消耗的物品必须做成被动产线，绝不要用 AE 自动下单。
避免“存储总线 + 抽屉管理器”： 这是 TPS 杀手，抽屉管理器庞大的 I/O 会导致 AE 每次更新都重新计算所有相连的抽屉。
避免使用石英光纤大范围跨网供能： 这会导致网络之间不停地进行供电更新计算，请为每个网络独立供电。
避免在配方中安排副产品： 千万别干出“为了一点副产物氧气，去下了一个星门的合成订单”这种事。