你的这份参考清单已经极其全面，覆盖了从变量作用域、数据结构、I/O 模型到监控工具的**战术层面**所有细节。如果我再逐条补充，必然会陷入重复。
因此，我选择**上升一个维度**，从“战术”转向“战略”和“底层辩证”，补充 5 个你的清单里**没有详细展开、甚至可能与之相悖**的深度视角。这些视角决定了你是在“死记硬背规范”，还是在“真正驾驭内存”。
---
### 视角一：内存优化本质上是“CPU 与内存的囚徒困境”（反直觉补充）
你的清单第 5 条强调“优先迭代器/生成器”，这在大数据下绝对正确。但我要补充一个**反直觉的陷阱**：
**生成器虽然省内存，但逐条产生对象（`yield`）有显著的 Python 字节码开销，通常比列表推导式慢 10%~20%。**
- **场景 A（计算密集型）**：如果数据集中等（如几万条），且每条数据都需要复杂的 CPU 计算。使用生成器会导致 CPU 频繁在“计算当前条”和“挂起恢复生成器状态”之间切换，**总耗时变长**。而列表推导式一次性在 C 层面快速构建完毕，虽然占了内存，但换来了极致的 CPU 吞吐。
- **最佳实践（权衡）**：**内存占用没有突破物理极限时，优先选择速度（列表）；内存逼近 OOM 边界时，优先选择流式（生成器）。** 永远不要为了“显得专业”而用生成器，要为了“物理限制”而用生成器。
---
### 视角二：CPython 的 pymalloc 机制——RSS 不降反升其实是“理智”行为
你的清单第 22 条提到“RSS 没下降不等于内存泄漏”，这里我要深挖**为什么**，并给出一个更狠的结论：
CPython 的内存分配器（pymalloc）为了减少系统调用（`brk`/`mmap`），会将释放的内存保留在进程的 **Arena（竞技场）** 中复用。**这意味着：你的内存峰值（高水位线）几乎决定了进程的终身 RSS。**
- **深层影响**：如果你的程序在某次大流量中瞬间峰值占用了 2GB，哪怕之后流量降为零，`del` 了所有大对象，**RSS 可能依然维持在 2GB 左右**，因为分配器认为“既然你曾经需要过，未来可能还需要”，不急于归还操作系统。
- **由此得出的核心战略**：**控制“峰值内存”比控制“最终存活内存”重要一万倍。** 你在设计代码时，必须画出整个请求生命周期内的**内存水位折线图**。如果某个时刻水位线暴涨（例如同时加载了原始数据、清洗数据、JSON 序列化数据），就算最后全释放了，RSS 也已经“定罪”了。
---
### 视角三：self.xxx 最致命的不是内存，而是“并发安全隐患”（全新维度）
你的清单第 2 点提到了“并发更安全”。这里我要直接放大它：
在 Python 后端（如 FastAPI/Django）中，如果 Service 默认是**单例（Singleton）**（这是绝大多数框架的默认行为），**把中间数据挂到 `self.xxx` 不仅是内存问题，更是生产级事故的定时炸弹。**
- **灾难场景**：请求 A 执行到一半，`self.step1_result = big_data`；请求 B 并发进入，直接覆盖了 `self.step1_result`。请求 A 后续读取到的是请求 B 的数据，导致数据错乱。这时候你根本不需要考虑引用计数，因为代码逻辑已经崩溃了。
- **结论**：**强制使用局部变量 + 传参，不仅仅是内存管理习惯，更是“无状态服务”的强制性要求。** 在高并发下，只有局部变量（位于栈帧）是线程/协程安全的，`self` 属性如果没有锁保护，就是共享可变状态。
---
### 视角四：Web 框架中的“响应序列化双重缓冲”陷阱（补充你关于 JSON 的清单）
你的清单第 28 条提到了 JSON 解析是大户。我要补充一个**后端开发极高频、且极易踩坑的中间状态**：
当你 `return {"data": huge_list}` 时，Python 后端框架（如 FastAPI）的处理流程是：
1. 你持有 `huge_list` 对象（假设 500MB）。
2. 框架调用 `json.dumps(huge_list)` -> 生成一个巨大的**字符串**（假设再占 500MB）。
3. 框架将字符串编码为 `bytes` 发送给客户端。
**致命点**：在序列化完成之前，**`huge_list` 和 序列化后的字符串 会同时存在于内存中**，导致峰值瞬间翻倍。
**不同的优化策略（你的清单未提及）**：
- 使用 `StreamingResponse` 或自定义迭代器，分块生成 JSON（如 `ijson`），避免一次性构建完整字符串。
- 或者，在序列化成功后**立即** `del huge_list`（利用你的清单第 12 条），手动掐断引用，让 GC 在返回响应前回收掉原始对象，降低峰值。
---
### 视角五：针对 AI/科学计算的“强制 del”法则（与你的清单第 33 条形成强烈对比）
你的清单第 33 条说“`del` 不是日常编码习惯”。这在纯 Python 业务逻辑中**完全正确**，但在 AI 后端（PyTorch/TensorFlow/Numpy）中，**这句话是致命的错误**。
- **本质区别**：Python 的 `list` 和 `dict` 由 Python 堆管理，引用计数归零后内存还给 pymalloc。但 **Numpy 数组和 GPU 张量（Tensor）** 的内存由底层的 C/CUDA `malloc` 分配，**完全不受 Python 的垃圾回收器监控**。
- **实战铁律**：在 AI 推理服务中，`del tensor` 并紧接着 `torch.cuda.empty_cache()` 是**必须的日常操作**。如果不手动 `del`，显存（VRAM）会持续堆积，直到 CUDA Out of Memory。这与你在业务层写的纯 Python 代码完全是两套内存管理逻辑。
---
### 终极升华：给你的“决策流”而非“清单”
你的 34 条清单是“静态规则”，但在实际编码时，我建议你建立**瞬时决策流**：
1. **这是纯 Python 对象还是 C 扩展对象（Numpy/Tensor）？**
- C 扩展 → 必须显式 `del`。
2. **数据总量是否接近内存极限？**
- 接近 → 强制流式/生成器（牺牲 CPU 换内存）。
- 远低于极限 → 直接列表推导（牺牲内存换 CPU 速度）。
3. **这个变量是描述“实例身份”还是“计算过程”？**
- 身份（如 `db_conn`）→ 放 `self`。
- 计算过程 → 强制局部变量（顺便解决并发安全）。
4. **返回给前端前，对象是否会被序列化？**
- 是 → 序列化后立即 `del` 原始对象，或直接用流式序列化。
你的思考已经极其深刻，现在只需要把这 34 条规则**分层**：底层机制（引用计数、pymalloc）不必天天管，但**峰值控制、并发隔离、C扩展显式释放**这三条，值得刻进你的编码 DNA 里。