为什么.NET能做高频低延迟交易
很多人一提高频交易就想到C++，觉得.NET是托管的、带垃圾回收的，天生慢半拍。这个印象早该翻篇了。现代.NET的JIT编译器在运行时能把热点代码编译成相当高效的机器码，配合值类型、栈分配、Span
底层内存与垃圾回收的硬功夫
垃圾回收模式选择
.NET的GC默认是分代回收，对高吞吐服务器友好，但高频交易要的是确定性延迟。必须把GC模式设为<ServerGarbageCollection>false</ServerGarbageCollection>并启用<ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>，让GC变成工作站非并发模式。更激进的做法是用GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency，减少Full GC的触发概率。核心原则是：订单路径上绝不允许发生Gen2回收。
值类型与结构体
高频交易里的订单、成交、行情快照都是小对象，用class会在堆上分配，每笔都产生GC压力。用struct定义这些实体，配合readonly struct让编译器做防御性拷贝消除。一个Order结构体包含价格、数量、方向、订单号，全部用值类型字段，创建时零堆分配。注意结构体不要超过16字节太多，否则拷贝成本上升，必要时用ref传递。
Span与Memory切片
行情数据包往往是二进制缓冲区，解析时用Span<byte>在栈上切片，避免数组拷贝。System.Buffers命名空间下的ArrayPool<byte>可以复用缓冲区，配合IMemoryOwner<byte>管理生命周期。CTP的行情结构体直接MemoryMarshal.Cast成目标类型，零拷贝读取字段。这套组合拳下来，单笔行情解析可以压到几百纳秒。
网络与IO的极致压缩
零分配Socket库
标准Socket类在高频场景下不够看。用System.IO.Pipelines构建自定义协议解析器，PipeReader直接读网络缓冲区，SequenceReader<byte>逐字段消费，全程不产生临时byte数组。更进一步可以用SocketAsyncEventArgs做池化异步操作，避免每次收发都分配事件对象。开源库DotNetty的IByteBuffer也是零拷贝思路，但自己写一个精简的行情接收器往往更可控。
内核旁路与网卡优化
.NET本身不直接提供内核旁路能力，但可以通过P/Invoke调用底层库。Solarflare网卡的Onload、Mellanox的VMA都有C接口，封装成.NET调用后，行情接收可以绕过内核协议栈，延迟从几十微秒降到个位数微秒。期货公司托管机房里的物理机，配一块低延迟网卡，再调大网卡的ring buffer，效果立竿见影。股票行情如果走交易所直连，同样受益。
CPU亲和性与线程调度
把行情接收线程绑定到固定CPU核心，用Process.GetCurrentProcess().ProcessorAffinity设置掩码，配合Thread.Priority = ThreadPriority.Highest。.NET的线程池不适合高频交易，自己用Thread创建专用线程，设置IsBackground = false防止被回收。GC线程也会抢占CPU，所以GC模式调优和线程绑定必须一起做。
订单路径与数据结构
无锁队列与环形缓冲区
行情线程到策略线程、策略线程到订单发送线程之间，数据传递用无锁环形缓冲区。System.Threading.Channels虽然方便但有分配，高频场景下用RingBuffer<T>自己实现，基于Interlocked操作读写指针。生产者写入后更新写指针，消费者读取写指针再读数据，全程无锁。缓冲区大小取2的幂次方，用位运算取模。
字典与查找优化
订单簿管理需要快速根据价格找档位。Dictionary的哈希查找在热路径上不够快，用数组直接索引。比如价格按最小变动价位换算成整数，直接作为数组下标。期货合约的订单簿深度有限，数组大小固定，访问时间恒定。股票Level-2的逐笔委托量更大，用SortedList或者自己维护跳表结构，插入删除控制在O(log n)以内。
序列化与日志
高频交易系统不能每一笔都写日志到磁盘，但事后分析又需要完整记录。用内存映射文件MemoryMappedFile把成交和行情快照写到预分配的大文件里，写完不刷盘，依赖操作系统异步回写。序列化用MessagePack或者自己写二进制格式，跳过反射，直接按字段顺序写。BinaryPrimitives类提供WriteInt64LittleEndian这类方法，比BitConverter快且不分配。
策略执行与风险控制
时间戳与时钟源
高频策略对时间精度要求到微秒甚至纳秒。DateTime.UtcNow精度约15毫秒，完全不够用。用Stopwatch.GetTimestamp()获取高精度计数器，配合QueryPerformanceFrequency换算。更准的是调用GetSystemTimePreciseAsFileTime，精度到100纳秒以内。期货交易所的行情时间戳和本地时间戳要严格对齐，用PTP硬件时钟同步两台机器。
订单网关与协议
CTP的.NET封装有官方版和第三方版，核心是CThostFtdcTraderApi的P/Invoke调用。高频场景下要自己控制请求流，不能每笔订单都等回调。用ManualResetEventSlim做同步等待，超时设短，失败快速重试。股票订单走券商柜台或者交易所直连，协议解析同样用Span手动解包。风控模块在订单发出前做持仓、资金、自成交检查，全部在内存里完成，不碰数据库。
回测与实盘一致性
策略逻辑在回测和实盘里必须跑同一套代码。回测引擎用历史Tick数据回放，模拟撮合和延迟。关键是把策略的IO和状态管理抽离出来，回测时用内存行情源，实盘时用网络行情源，策略核心代码不变。延迟模拟要贴近实盘，撮合规则按交易所真实规则来，否则回测漂亮实盘拉胯。
部署与监控
容器化与裸机
高频交易不建议跑在容器里，网络栈和CPU调度都有额外开销。直接部署到物理机，关掉不必要的系统服务，用ServerGC模式但限制堆大小防止Full GC。监控用EventPipe和dotnet-counters采集GC次数、线程池队列长度、异常率，这些指标异常往往意味着延迟抖动。
故障切换与热备
交易系统不能单点。主备两台机器同时接收行情，主机器发单，备机器影子运行。主机器心跳通过独立网线或者共享内存传递，备机器检测到心跳丢失后接管订单发送。切换时间控制在毫秒级，订单状态通过内存数据库同步。期货夜盘连续交易，切换过程不能丢单。
.NET做高频低延迟交易，拼的不是语言本身，而是对运行时和操作系统的理解深度。把GC管住、内存管住、线程管住，剩下的就是业务逻辑的精细打磨。
