C#中Stack是最标准、安全且高性能的LIFO实现，因其Push/Pop/Peek均为O(1)、语义严谨、空栈保护明确，而List模拟栈存在O(n)遍历、内存重分配、破坏抽象及异常语义不清等问题。
直接说结论：C# 中用 Stack<t></t> 就是最标准、最安全、性能也最好的 LIFO 实现，别手写数组或 List 模拟栈逻辑。
为什么必须用 Stack<t></t> 而不是 List<t></t> + Last()？
很多人图省事，用 List<t></t> 存数据，再靠 list.Last() 取“栈顶”，list.RemoveAt(list.Count - 1) 模拟 Pop —— 这看似可行，但实际踩坑不断：
-
Last()是 LINQ 方法，每次调用都遍历整个列表，O(n)时间复杂度；而Stack<t>.Peek()</t>是O(1) -
RemoveAt(list.Count - 1)触发内部数组收缩判断，可能引发不必要的内存重分配；Stack<t>.Pop()</t>只挪动一个指针，无拷贝 -
List<t></t>允许随机访问索引，破坏了栈的抽象契约——一旦有人误用list[0]或list.Insert(0, x)，LIFO 行为就不可控了 - 没有空栈保护：
Pop()在空Stack<t></t>上会明确抛InvalidOperationException；而list.RemoveAt(-1)直接是ArgumentOutOfRangeException，语义不清晰
Stack<t></t> 的三个核心操作怎么写才不出错？
记住：所有操作只作用于栈顶，且必须按语义使用。常见错误不是语法错，而是逻辑错：
-
Push()：永远添加到栈顶，不要在循环里反复Push同一个引用对象（比如Push(new MyClass())写在循环外，会导致栈里全是同一实例） -
Pop()：一定先判空，尤其在解析嵌套结构（如括号匹配、XML 标签栈）时，漏判会导致崩溃。推荐写法：if (stack.Count > 0) { var top = stack.Pop(); }，别依赖 try/catch 捕获异常来控制流程 -
Peek()：仅查看，不移除。注意它和Pop()的返回值类型完全一致，但行为天差地别；调试时容易把Peek()当成“安全版 Pop”，结果逻辑卡死
泛型约束和 null 值处理要注意什么？
Stack<t></t> 支持值类型和引用类型，但 null 的行为差异极大：
- 对引用类型（如
Stack<string></string>），Push(null)合法，Peek()返回null，Pop()也返回null - 对可空值类型（如
Stack<int></int>），Push(null)合法；但对非空值类型（如Stack<int></int>），Push(null)编译不过，会报 CS0037 - 如果业务中需要区分“栈为空”和“栈顶为 null”，不能只靠
Count == 0判断，得结合业务上下文设计标记值（比如用Stack）
性能敏感场景下，Stack<t></t> 的扩容机制怎么影响你？
Stack<t></t> 内部用数组实现，初始容量是 0，第一次 Push 后自动分配长度为 4 的数组；之后每次满时按 2 倍扩容（4→8→16→…）。这意味着：
- 如果你知道栈最大深度（比如解析深度不超过 100 层的 JSON），初始化时显式指定容量能避免多次扩容：
new Stack<string>(128)</string> - 频繁
Push/Pop导致容量来回震荡（比如压入 200 个再弹出 190 个，再压入 200 个），不会自动缩容——内存占用只增不减。此时若生命周期长、复用频繁，建议每次用完后Clear()，或改用Stack<t></t>局部变量（方法退出即释放） - 不要为了“节省内存”而反复 new/Dispose
Stack<t></t>：对象创建开销远大于一次扩容，除非栈大小波动极大且不可预测
真正容易被忽略的点是：栈不是线程安全的。多个线程同时 Push 或 Pop 同一个 Stack<t></t> 实例，结果不可预测——.NET 没有提供内置的线程安全栈类型，需要自己加锁，或改用 ConcurrentStack<t></t>（但它的 Peek() 不保证和下次 Pop() 看到同一元素）。
