在Go语言垃圾回收机制的历史演进中，曾提出或尝试过哪些设计最终未被采纳？这些设计被否决的原因分别是什么？

回答思路

1. 【回答框架 1】Go GC的演进主要围绕降低延迟和提升吞吐，历史上讨论过但未采用的设计包括引用计数、分代GC、部分保守式GC等。引用计数因循环引用处理复杂且运行时开销大，与Go的并发模型不匹配而被放弃。
2. 【回答框架 2】分代GC虽能提升吞吐，但需要写屏障和记忆集，增加内存开销和实现复杂度，且Go的分配模式（大量短生命周期对象）可能使分代优势不明显，因此未采用。
3. 【回答框架 3】部分保守式GC能减少扫描范围，但可能无法精确识别所有指针，导致内存泄漏风险，Go选择了精确GC以保证安全性。
4. 【回答框架 4】其他如并行标记删除的变体、无STW的GC（如Azul的C4）也曾被考虑，但受限于工程实现难度和与调度器的交互，最终未在Go中落地。
5. 【回答框架 5】关键取舍在于延迟目标（<1ms）与吞吐、实现复杂度之间的平衡，Go团队选择了相对简单且可预测的并发三色标记清除，并不断优化其停顿时间。
6. 【关键点 1】引用计数因循环引用处理复杂和运行时开销大而被放弃。
7. 【关键点 2】分代GC因内存开销和实现复杂度，且Go分配模式可能不适用而未采用。
8. 【关键点 3】保守式GC因内存泄漏风险被精确GC取代。
9. 【关键点 4】无STW方案（如C4）因工程难度和与调度器交互问题未落地。
10. 【关键点 5】Go选择并发三色标记清除，并持续优化停顿时间。
11. 【易错点 1】误认为Go GC从未考虑过分代或引用计数，实际上这些均有讨论和实验。
12. 【易错点 2】混淆三色标记清除与增量式GC，三色标记是并发标记的基础。
13. 【易错点 3】认为无STW是绝对目标，实际Go仍有极短的STW，只是极小化。