不能用 queue[0] 因为 Queue<T> 未定义索引器，编译直接报错 CS0021；多线程下需用 ConcurrentQueue<T> 的 TryDequeue/TryPeek，避免竞态与异常。
别用 queue[0]，也别靠 Count 判断是否能 Dequeue —— 会崩；多线程场景下直接用 ConcurrentQueue<T>，手写 lock 包一层是假安全。
为什么不能用 queue[0] 访问队首？
因为 Queue<T> 没有定义索引器。编译器会直接报错：CS0021 Cannot apply indexing with [] to an expression of type 'Queue<T>'。这不是运行时异常，是编译期拦住你。
- 想看但不取走队首？必须用
Peek()，且调用前要确认Count > 0，否则抛InvalidOperationException - 想跳过前 N 项？别循环
Dequeue()再丢弃 —— 如果只是临时读取、不真移除，就转成数组：queue.ToArray()，注意这会分配新内存，且顺序就是入队顺序 - 如果只是想“取第 N 个”，说明你其实需要的是
List<T>或Array，不是队列
Enqueue/Dequeue 在多线程下为什么危险？
Queue<T> 默认完全不保证线程安全。两个线程同时 Enqueue，可能造成内部头尾指针错位、Count 和实际元素数不一致，甚至静默丢数据——不会 crash，但结果不可信。
-
lock包住单次Enqueue或Dequeue不够：比如你先读Count > 0再调Dequeue()，中间可能被其他线程抢先取走，导致Dequeue()抛异常 - 真正安全的做法是换用
ConcurrentQueue<T>：它提供TryDequeue(out T)和TryPeek(out T)，返回bool表示操作是否成功，无异常、无竞态 - 不要为了“省一个 using”而复用非线程安全队列在后台任务或 ASP.NET Core 请求处理中
泛型类型选错会埋什么雷？
Queue<object> 能塞进任何东西，编译不报错，但后续 Dequeue() 返回 object，强转失败只在运行时暴露，调试困难。
- 该用
Queue<string>就别写Queue<object>；该用Queue<int?>就别用Queue<object>去装 null - 值类型（如
int）放进非泛型Queue会触发装箱，性能差且 GC 压力大；泛型Queue<int>零开销 - 如果你需要存多种类型，考虑用
Queue<IConvertible>或自定义基类/接口，而不是退回到object
内存一直涨，是不是 Queue 泄漏了？
Queue<T> 内部用动态数组实现，Dequeue() 后空间不自动收缩，但也不会持续增长——除非你忘了清理引用。
- 大量短生命周期对象入队后没出队，或出队后仍被其他变量持有（比如存了事件回调、闭包捕获），GC 不会回收
- 复用同一个
Queue<T>实例做循环处理时，记得定期Clear()，尤其当元素是引用类型 -
TrimToSize()可强制收缩容量，但多数场景没必要；频繁调用反而影响性能
最容易被忽略的其实是「类型声明即契约」：写 Queue<Customer> 就意味着所有消费代码都默认能拿到 Customer，而不是靠一堆 as Customer 和 null 检查硬扛——这点比怎么调用 Enqueue 重要得多。
