# Memscope-rs 已知局限
> 本文档诚实记录 memscope-rs 的技术局限和设计取舍。
>
> 作为独立开发者，我必须在"全部数据"和"真实性"之间做出取舍。
---
## 核心局限
### 1. 无法真实采集的数据
Rust 运行时没有提供所有必要的 hook，以下数据**无法在运行时自动采集**：
| **借用信息** (`borrow_info`) | Rust 没有 `&T`/`&mut T` 创建时的 hook | 推测引擎 |
| **智能指针信息** (`smart_pointer_info`) | 需要 `Rc::clone`/`Arc::clone` 插桩 | 推测引擎 |
| **内存布局** (`memory_layout`) | 需要编译时类型信息 | 推测引擎 |
| **泛型信息** (`generic_info`) | 类型擦除，运行时不可见 | 推测引擎 |
### 2. 推测引擎的局限
对于无法真实采集的数据，我们使用推测引擎进行估算。**但请注意**：
- ⚠️ **推测结果可能是错的**
- ⚠️ **依赖启发式规则，可能不适用于所有场景**
- ⚠️ **无法验证正确性**
**推测数据会在输出中明确标注**，例如：
```json
{
"borrow_info": {
"immutable_borrows": 5,
"_source": "inferred", // 标注为推测
"_confidence": "low" // 置信度
}
}
```
### 3. 多线程/异步追踪的局限
| **跨线程移动** | 变量移动后难以追踪原始来源 |
| **异步任务** | task_id 在不同 runtime 行为不同 |
| **Arc 共享** | 难以确定"真正"的拥有者 |
---
## 设计取舍
### 取舍 1：真实性 vs 完整性
- **选择**：优先保证真实数据的正确性
- **代价**：部分数据需要推测
- **原因**：错误的真实数据比没有数据更糟糕
### 取舍 2：性能 vs 功能
- **选择**：保持低开销（< 5%）
- **代价**：无法实现某些高开销功能
- **原因**：内存分析器不能成为性能瓶颈
### 取舍 3：通用性 vs 精确性
- **选择**：支持多种场景（单线程、多线程、异步）
- **代价**：某些场景下精确度降低
- **原因**：实用性优先
---
## 未来方向
### 短期（可行）
- [ ] 改进推测引擎的准确度
- [ ] 提供手动插桩 API
- [ ] 优化性能
### 中期（需要研究）
- [ ] 探索 IR 插桩方案（需要 Nightly Rust）
- [ ] 与 Tokio/async-std 深度集成
- [ ] 支持 eBPF 追踪
### 长期（需要编译器支持）
- [ ] Rust 编译器插件支持
- [ ] 官方内存追踪 API
---
## 贡献
如果你有解决这些局限的想法，欢迎：
1. 提 Issue 讨论
2. 提 PR 贡献代码
3. 分享你的使用场景
---
## 致谢
感谢所有理解并接受这些局限的用户。
> "正视缺陷，诚实面对，这才是真正的工程师精神。"
---
**最后更新**: 2026-04-12
**项目状态**: 研究型项目，持续更新