DMA 设备在游戏自动化中的实战：硬件直读内存、TLP 链路与 MemProcFS 对接

上一篇聊了采集卡方案——从 HDMI 输出口"劫持"视频信号，送另一台机器做图色识别。那条路线的瓶颈很明显：延迟在几十到上百毫秒级别，而且图像识别本身也有计算开销。如果游戏数据本质上就存在内存里（血量、坐标、CD 计时器、怪物列表），为什么要绕一大圈先把内存渲染成画面、再把画面拍回来识别？直接读内存不就行了。

问题在于"直接读内存"这件事在反作弊环境下极其困难。主流端游的反作弊驱动（Vanguard、BattlEye、EAC、ACE）都挂在内核层，hook 了 MmCopyVirtualMemory、监控 NtReadVirtualMemory 的调用栈，你从同机的用户态或内核态发起的任何内存读取都会被拦截。软件方案走到这里基本死路一条。

DMA 设备（Direct Memory Access 硬件）换了个思路：不碰目标机器的 CPU 和操作系统，直接从 PCIe 总线层面以硬件身份发起内存读取请求。反作弊驱动跑在操作系统里，DMA 设备跑在 PCIe 总线上——两者不在同一个层面，软件层看不到硬件层的事。这就是 DMA 方案的核心价值：它不绕过反作弊，它绕过的是反作弊所在的整个软件层。

DMA 设备的硬件架构：两台机器之间插了什么

DMA 方案的物理拓扑是双机方案——目标机（运行游戏的机器）和操作机（跑自动化脚本的机器）是两台独立的 PC，中间通过 PCIe 总线连接。连接媒介就是 DMA 设备本身：一块 PCIe 卡，插在目标机的 PCIe 插槽里，同时通过 USB 3.0 接口连到操作机。

关键点在于：DMA 卡插在目标机的 PCIe 插槽上，但目标机的操作系统看不到它是一个可疑设备。DMA 卡的固件会把自己伪装成一个合法的 PCIe 设备——最常见的是伪装成 Intel I225-V 千兆网卡或者 NVIDIA 系列的 USB 显示适配器。目标机的 PCI 枚举看到的是一个"正常的硬件设备"，不会产生告警。

DMA 卡的核心是Xilinx Artix-7 系列 FPGA。不同型号对应不同性能档次：

速度差异主要来自 FPGA 的逻辑单元数量——更多的逻辑单元可以容纳更宽的数据通路和更深的 FIFO 缓冲。但要注意，标称速度是 PCIe DMA 引擎的理论上限，实际通过 USB 传到操作机时，USB 3.0 的有效带宽（约 350~400 MB/s）是硬天花板。75T 和 100T 在实际使用中的差距远没有理论值那么大——瓶颈在 USB 传输，不在 FPGA。

踩坑记录：买了一块 100T 双口板，满怀期待地以为速度能比 35T 快四倍，结果实测读取速度只比 35T 快了不到 30%。后来看 USB 总线分析才发现，PCIe 侧的数据早就到了 DMA 卡的 USB 控制器，但 USB 3.0 的实际传输带宽卡在 380MB/s 左右，FPGA 再快也白搭。如果不需要做大范围内存扫描（只读固定偏移），35T 和 100T 的体感差距几乎为零。钱花在 FPGA 上不如花在固件优化上。

TLP 事务：DMA 读内存的底层机制

要理解 DMA 设备为什么能读内存，需要先理解 PCIe 总线的事务模型。PCIe 总线上的所有数据传输都通过 TLP（Transaction Layer Packet，事务层包）来完成。一个 TLP 就是一个数据包，包含：

• 格式/类型字段（Fmt/Type）：标识这是读请求、写请求、还是完成包
• 地址字段：目标物理内存地址（64 位或 32 位）
• 长度字段：要读取/写入的数据长度，以 DW（Double Word，4 字节）为单位
• Requester ID：发起者的 Bus/Device/Function 号——DMA 卡伪造一个合法的 BDF
• Tag：请求标识符，用于匹配请求和完成包

DMA 卡读取内存的完整流程是这样的：

整个过程中，目标机的 CPU 和操作系统完全不参与。CPU 不知道有人读了它的内存——因为读请求直接打到了内存控制器，没有经过 CPU 的指令流水线。操作系统也不知道——因为操作系统通过驱动程序管理 PCIe 设备，但 DMA 卡发出的 TLP 不经过任何软件驱动处理，直接在硬件总线上完成事务。这就是"硬件层"和"软件层"的隔离原理。

单次 TLP 读请求的最大有效载荷是 128 字节（受 Max Payload Size 限制，多数主板设置为 128 或 256B）。要读 4KB 的数据需要拆成 32~64 个 TLP。但 DMA 卡固件可以批量提交多个读请求，利用 PCIe 的流水线特性让多个 TLP 在总线上"排队"执行，不需要等前一个完成再发下一个。这就是为什么批量连续读取比随机零散读取快得多——连续地址的 TLP 可以合并成一次大传输，零散地址每个都要单独走一遍完整流程。

软件栈：PCILeech + MemProcFS

DMA 卡是硬件，但光有硬件不能干活——你需要一套软件来发读请求、解析返回数据。目前事实上的标准方案是 PCILeech（底层硬件接口库）+ MemProcFS（内存分析框架）的组合。这两个都是 ufrn（Ulf Frisk）开源的项目。

PCILeech 是直接操作 DMA 硬件的底层库。它提供了 LeechCore API，可以发原始的 DMA 读/写请求。你在 Python 里调 leechcore.LeechCore.read()，底层就是 PCILeech 在构造 TLP、发送、等待 Completion、提取数据。

MemProcFS 构建在 LeechCore 之上，它把整个目标机的物理内存映射成一个虚拟文件系统。你可以在操作机上像浏览文件夹一样浏览目标机内存：

# 操作机上的 MemProcFS 虚拟目录结构（示例）
M:\
├── pid/                          # 按进程 ID 组织
│   ├── 1234/                     # 进程 PID 1234
│   │   ├── name.txt              # 进程名：game.exe
│   │   ├── modules/              # 该进程加载的所有模块
│   │   │   ├── game.exe/         # 主模块
│   │   │   │   ├── base.txt      # 基址: 0x7FF600000000
│   │   │   │   └── pe/           # PE 文件解析
│   │   │   └── kernel32.dll/
│   │   ├── vad.txt               # 虚拟地址描述符
│   │   └── memory/               # 进程虚拟内存读写
│   └── 5678/
├── kmd/                          # 内核模块信息
├── sys/                          # 系统信息（CPU、内存布局）
│   ├── memory.txt                # 物理内存布局
│   └── dtb.txt                   # 页目录基址
└── forensic/                     # 取证信息

MemProcFS 的核心能力是虚拟地址到物理地址的翻译。你的游戏进程里的变量存在虚拟地址空间（比如 0x7FF600001234），但 DMA 只能读物理地址。MemProcFS 自动做了页表遍历——读取 CR3 寄存器拿到页目录基址，逐级遍历 PML4→PDPT→PD→PT，最终把虚拟地址翻译成物理地址，然后发 DMA 读请求。你只需要关心虚拟地址，翻译过程透明。

Python 对接：VmmPython 实战代码

MemProcFS 提供了 Python 绑定库 VmmPython。先装好 PCILeech 驱动和 MemProcFS，确保 DMA 设备被识别，然后：

from MemProcFS import VmmInstance
import struct

# 初始化 MemProcFS，自动检测 DMA 设备
vmm = VmmInstance()

# ========== 第一步：找到目标进程 ==========
# 方法1：按进程名查找
pid = vmm.get_pid_from_name("game.exe")
if pid == 0:
    print("进程不存在，检查游戏是否启动")
    exit()

# 方法2：列出所有进程，自己匹配
# for proc in vmm.process_list():
#     if "game" in proc.name.lower():
#         pid = proc.pid
#         break

print(f"目标进程 PID: {pid}")
process = vmm.get_process(pid)

# ========== 第二步：读取模块基址 ==========
# 拿到主模块的基址和大小
game_module = process.get_module("game.exe")
base_addr = game_module.base_address  # 例如 0x7FF600000000
module_size = game_module.module_size
print(f"模块基址: {hex(base_addr)}, 大小: {module_size}")

# ========== 第三步：读取内存 ==========
def read_int32(vaddr):
    """读4字节整数"""
    data = process.memory.read(vaddr, 4, is_vmm=False)
    if len(data) == 4:
        return struct.unpack("<I", data)[0]  # 小端序
    return None

def read_float(vaddr):
    """读4字节浮点数（坐标/血量常用）"""
    data = process.memory.read(vaddr, 4, is_vmm=False)
    if len(data) == 4:
        return struct.unpack("<f", data)[0]
    return None

def read_bytes(vaddr, size):
    """批量读取"""
    return process.memory.read(vaddr, size, is_vmm=False)

# ========== 第四步：指针链解引用 ==========
def read_pointer_chain(base, offsets):
    """
    多级指针读取：
    base = 模块基址 + 初始偏移
    offsets = [偏移1, 偏移2, 偏移3, ...] 逐级解引用
    """
    addr = base
    for i, offset in enumerate(offsets):
        data = process.memory.read(addr + offset, 8, is_vmm=False)
        if len(data) != 8:
            print(f"第{i}级指针读取失败")
            return None
        addr = struct.unpack("<Q", data)[0]  # 64位指针
        if addr == 0:
            print(f"第{i}级指针为空")
            return None
    return addr  # 最终地址

# 实际使用：读取玩家血量
# 假设血量在 [game.exe + 0x04821A0] -> +0x10 -> +0x8 -> +0x4C 处
player_base = read_pointer_chain(base_addr + 0x04821A0, [0x10, 0x8])
if player_base:
    hp = read_int32(player_base + 0x4C)
    hp_max = read_int32(player_base + 0x50)
    print(f"血量: {hp}/{hp_max}")

# 读取玩家坐标（浮点数）
if player_base:
    x = read_float(player_base + 0x60)
    y = read_float(player_base + 0x64)
    z = read_float(player_base + 0x68)
    print(f"坐标: ({x:.2f}, {y:.2f}, {z:.2f})")

vmm.close()

这段代码里有三个实操要点：

要点一：指针链不是一次读出来的。多级指针意味着每解一级要做一次内存读取，而每次 DMA 读取都有延迟。四级指针链 = 4 次串行 DMA 读请求。如果每次请求 5~20μs（取决于地址是否在缓存行内），四级链路就是 20~80μs。听起来不多，但如果你每帧要读 50 个不同的指针链（血量、蓝量、坐标、buff 列表、目标列表……），串行读就是 1~4ms，累积起来不可忽视。

要点二：批量读取比逐个读取快一个数量级。与其读 50 次 read(addr+0x4C, 4)，不如一次读 read(player_base, 0x200)，把整个玩家结构体一次性拉回来，然后在 Python 侧用 struct.unpack 拆字段。原因前面说过了——连续地址的 TLP 可以合并成大传输，零散地址每次单独走流程：

# 优化前：50次串行读取
hp = read_int32(player_base + 0x4C)
mp = read_int32(player_base + 0x50)
x = read_float(player_base + 0x60)
# ... 重复47次，总耗时约 250~1000μs

# 优化后：1次批量读取 + Python侧解析
import struct

# 一次性读取 512 字节（覆盖整个玩家结构体）
raw = read_bytes(player_base, 512)
if len(raw) == 512:
    # 按偏移切片解析
    hp, mp = struct.unpack_from("<II", raw, 0x4C)
    x, y, z = struct.unpack_from("<fff", raw, 0x60)
    # 总耗时约 5~20μs（单次 DMA 读 + USB 传输）

要点三：is_vmm=False 的含义。MemProcFS 有两种读取模式：is_vmm=False 表示直接读虚拟内存（走页表翻译），is_vmm=True 表示读 MemProcFS 的内部缓存。第一次读一定用 False（触发真实 DMA），但如果你要频繁读取同一地址（比如每帧都读血量），可以用 True 先查缓存——MemProcFS 会在页表翻译后缓存物理地址映射，省去重复的页表遍历开销。

延迟对比：DMA vs 采集卡 vs 软件读取

三种方案放在一起比，延迟差距非常大：

DMA 方案在延迟上介于软件读取和采集卡之间——比软件读取慢 50~200 倍（因为要走 PCIe→USB 全链路），但比采集卡快 1500~10000 倍。5~20μs 的单次读取延迟对任何游戏自动化场景都绰绰有余——60fps 下一帧是 16.7ms，你的内存读取在微秒级，完全可以做到"每帧读取、每帧决策、每帧操作"的闭环。

但 DMA 方案最大的优势不是延迟，而是信息精度。采集卡只能看到像素——你必须用模板匹配去推断"屏幕上这个图标代表什么状态"，而且游戏 UI 变了你就要重新截图。DMA 直接读内存，拿到的是游戏内部的真实数据结构：血量是整数不是像素颜色、坐标是浮点数不是屏幕位置、怪物列表是结构体数组不是画面里的小色块。你不需要猜，数据就是数据。

标了星号的"不可见"需要加一个注脚。传统反作弊（Vanguard、BattlEye、EAC）是软件层的，确实看不到 DMA 的硬件读取行为。但新一代反作弊正在引入硬件层面的检测手段——比如检查 PCIe 设备列表中是否有异常设备、检测 DMA 设备伪装的设备 ID 与实际行为是否矛盾、通过 IOMMU（输入输出内存管理单元）限制非授权设备的内存访问。这部分后面单独说。

特征码扫描：游戏更新后偏移变了怎么办

DMA 方案最大的维护成本是偏移地址会随游戏更新变化。你花了一周找到血量在 [game.exe+0x04821A0]+0x10+0x8+0x4C，游戏更新一版，整个指针链全部失效，又得重新逆向。

解决方案是特征码扫描（Signature Scanning）——不硬编码偏移地址，而是在游戏代码段里搜索一段固定的指令模式，找到这段指令的位置，再根据指令中的相对偏移动态计算目标地址。游戏更新后只要核心逻辑没大改，指令模式还在，扫描就能重新定位。

def scan_pattern(vmm, process, module_name, pattern, mask):
    """
    特征码扫描：在模块代码段中搜索匹配的字节模式
    
    pattern: 字节列表，如 [0x48, 0x8B, 0x05, 0x00, 0x00, 0x00, 0x00]
    mask:    匹配掩码，'x'=必须匹配，'?'=通配符
             例如 'xx?xxxx' 表示第3字节可以是任意值
    
    返回匹配地址
    """
    module = process.get_module(module_name)
    base = module.base_address
    size = module.module_size
    
    # 一次性读取整个模块到操作机内存
    # 这里牺牲内存换速度——4MB模块读取约20ms，之后在本地搜索
    raw = process.memory.read(base, size, is_vmm=False)
    if len(raw) != size:
        print("模块读取失败")
        return None
    
    # 本地搜索
    results = []
    for i in range(len(raw) - len(pattern)):
        match = True
        for j in range(len(pattern)):
            if mask[j] == 'x' and raw[i + j] != pattern[j]:
                match = False
                break
        if match:
            results.append(base + i)
    
    return results

# 示例：搜索读取玩家血量的指令模式
# 游戏更新后偏移会变，但指令模式（如 mov rax, [rip+offset]）通常稳定
pattern = [0x48, 0x8B, 0x05, 0x00, 0x00, 0x00, 0x00, 0x48, 0x85, 0xC0]
mask    = "xx?xxxxxxx"  # 第3字节是RIP相对偏移的低字节，随更新变化

matches = scan_pattern(vmm, process, "game.exe", pattern, mask)
if matches:
    instruction_addr = matches[0]
    # 从指令中提取RIP相对偏移（偏移在指令的第4~7字节，小端序）
    raw = process.memory.read(instruction_addr + 3, 4, is_vmm=False)
    rip_offset = struct.unpack("<i", raw)[0]  # 有符号32位
    # 实际地址 = 下一条指令地址 + 偏移
    target_addr = instruction_addr + 7 + rip_offset  # 7 = 指令长度
    print(f"动态定位的地址: {hex(target_addr)}")
else:
    print("特征码未匹配，可能游戏大版本更新了，需要重新逆向")

特征码扫描的代价是首次定位慢（要扫整个模块，可能几十毫秒），但定位完之后把地址缓存下来，后续直接用缓存地址读取即可，直到下次游戏更新。实际工程中通常做成缓存优先、扫描兜底的策略：

1. 启动时先读本地缓存文件（存上次扫描到的偏移）
2. 用缓存偏移尝试读取，校验返回值是否合理（比如血量在 0~99999 之间）
3. 校验通过 → 直接使用缓存，跳过扫描
4. 校验失败 → 触发特征码扫描，重新定位，更新缓存

这样大多数情况下启动即用（几毫秒读完缓存偏移就能跑），只有游戏更新后的第一次启动需要花几十毫秒做扫描。

DMA + 采集卡混合方案：两条腿走路

实际做游戏自动化时，DMA 和采集卡不是二选一的关系，而是互补的。DMA 擅长读取结构化数据（血量、坐标、CD 计时器、物品列表），但不擅长判断"屏幕上现在显示的是哪个 UI 界面""BOSS 当前处于哪个阶段的哪种攻击模式"——这类信息往往通过视觉呈现而非单一内存值。采集卡恰好反过来。

混合方案的典型架构：

import threading
import time

class HybridGameBot:
    """DMA + 采集卡混合方案"""
    
    def __init__(self):
        # DMA 线程：持续读取游戏内存数据
        self.dma_data = {
            'hp': 0, 'mp': 0, 'x': 0.0, 'y': 0.0, 'z': 0.0,
            'target_hp': 0, 'buff_count': 0
        }
        self.dma_lock = threading.Lock()
        self.dma_running = False
        
        # 采集卡线程：持续抓帧（用前文的FrameGrabber）
        self.frame = None
        self.frame_lock = threading.Lock()
        self.frame_running = False
        
        # 决策线程：综合两个数据源做判断
        self.bot_running = False
    
    def dma_loop(self):
        """DMA线程：每5ms读取一次关键数据"""
        from MemProcFS import VmmInstance
        import struct
        
        vmm = VmmInstance()
        pid = vmm.get_pid_from_name("game.exe")
        process = vmm.get_process(pid)
        
        # 预定位玩家基址（缓存偏移）
        player_base = self.locate_player(process)
        
        while self.dma_running:
            # 批量读取玩家结构体（512字节一次DMA读）
            raw = process.memory.read(player_base, 512, is_vmm=False)
            if len(raw) == 512:
                hp, mp = struct.unpack_from("<II", raw, 0x4C)
                x, y, z = struct.unpack_from("<fff", raw, 0x60)
                
                with self.dma_lock:
                    self.dma_data.update({
                        'hp': hp, 'mp': mp,
                        'x': x, 'y': y, 'z': z
                    })
            
            time.sleep(0.005)  # 5ms间隔，200Hz更新率
    
    def frame_loop(self):
        """采集卡线程：持续抓帧"""
        import cv2
        cap = cv2.VideoCapture(1, cv2.CAP_DSHOW)
        cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)
        
        while self.frame_running:
            ret, frame = cap.read()
            if ret:
                with self.frame_lock:
                    self.frame = frame
            time.sleep(0.001)
        
        cap.release()
    
    def bot_loop(self):
        """决策线程：综合DMA数据 + 画面信息"""
        while self.bot_running:
            # 取DMA数据（微秒级，不阻塞）
            with self.dma_lock:
                dma = self.dma_data.copy()
            
            # 取最新帧（毫秒级）
            with self.frame_lock:
                frame = self.frame.copy() if self.frame is not None else None
            
            if frame is not None:
                # 用DMA数据做精确判断
                if dma['hp'] < 30:
                    print("血量低，吃药")
                    # self.arduino.send_key(KEY_HEAL)
                
                # 用画面做视觉判断（比如BOSS阶段识别）
                # roi = frame[y1:y2, x1:x2]
                # if match_boss_phase_2(roi):
                #     print("BOSS进入二阶段")
            
            time.sleep(0.001)
    
    def start(self):
        self.dma_running = True
        self.frame_running = True
        self.bot_running = True
        
        threading.Thread(target=self.dma_loop, daemon=True).start()
        threading.Thread(target=self.frame_loop, daemon=True).start()
        threading.Thread(target=self.bot_loop, daemon=True).start()
    
    def locate_player(self, process):
        """定位玩家基址（缓存优先，扫描兜底）"""
        import json, os
        
        cache_file = "offsets_cache.json"
        if os.path.exists(cache_file):
            with open(cache_file) as f:
                offsets = json.load(f)
            base = process.get_module("game.exe").base_address
            # 尝试用缓存偏移读取
            addr = self.read_pointer_chain(process, base + offsets['player_ptr'], offsets['player_offsets'])
            if addr:
                # 校验：读出来的血量在合理范围
                import struct
                raw = process.memory.read(addr + 0x4C, 4, is_vmm=False)
                if len(raw) == 4:
                    hp = struct.unpack("<I", raw)[0]
                    if 0 < hp < 999999:
                        return addr  # 缓存有效
        
        # 缓存失效，触发特征码扫描
        print("缓存偏移失效，开始特征码扫描...")
        addr = self.scan_and_update_cache(process)
        return addr

这个混合架构的核心设计是三线程解耦：DMA 线程负责高频内存读取（200Hz），采集卡线程负责持续抓帧，决策线程从两个数据源各取所需。三个线程通过锁保护共享数据，互不阻塞。DMA 数据更新到决策线程的延迟在微秒级（内存拷贝），画面数据在毫秒级——两者都远低于游戏的 16.7ms 帧间隔，决策线程能同时拿到"这一帧的内存状态"和"这一帧的画面"。

反作弊对抗：DMA 方案的当前处境与风险

DMA 方案的核心优势——"绕过整个软件层"——并不是永久的。虽然传统反作弊确实看不到 DMA 读取，但反作弊厂商不是吃素的，它们正在从多个方向围堵：

方向一：PCIe 设备白名单。部分反作弊开始枚举系统内所有 PCIe 设备，与已知合法设备数据库做比对。如果你的 DMA 卡伪装成 Intel I225-V 网卡，但系统里已经有一个真实的 I225-V 网卡（或者这个型号的网卡根本不该出现在你的主板配置里），就会被标记为可疑。对策是选择与你目标机硬件配置不冲突的伪装设备 ID，但这需要逐机定制，泛用性差。

方向二：IOMMU 硬件隔离。这是理论上最彻底的封锁。IOMMU（Intel VT-d / AMD-Vi）可以把 PCIe 设备限制在特定的内存区域内——如果反作弊或操作系统启用了 IOMMU 并把 DMA 设备的内存访问范围限制为零，DMA 就彻底废了。但 IOMMU 目前在消费级主板上默认关闭，而且开启后会对 GPU 等合法设备产生性能影响，所以还没有被大规模部署。这是一个悬在头顶的达摩克利斯之剑——一旦主流反作弊联合主板厂商推动 IOMMU 默认开启，整个 DMA 方案可能在一夜之间失效。

方向三：内存加密与混淆。不是封堵 DMA 读取本身，而是让你读到的数据没有用。游戏把关键数据（血量、坐标）在内存中加密存储，运行时才解密到 CPU 寄存器里用，内存里存的是密文。你 DMA 读回来的是加密值，不知道密钥就解不开。这种方案对游戏性能有影响（加解密开销），目前只有少数游戏在关键数据上做了加密，但如果普及，DMA 方案的"精确值"优势就大打折扣。

当前结论：截至现在，DMA 方案在大多数反作弊环境下仍然有效，但这是一个持续对抗的军备竞赛。做自动化项目时要评估目标游戏反作弊的检测强度，并做好 DMA 方案随时可能被封锁的预案——建议始终保留采集卡作为降级方案。

固件配置：BAR 大小与 Speed Profile

DMA 卡买回来不是插上就能用的，固件配置不对会导致各种莫名其妙的问题。两个最常见的配置项：

BAR（Base Address Register）大小。PCIe 设备通过 BAR 向系统声明自己需要多大的内存映射空间。DMA 卡通常需要配置一个 BAR 来作为数据传输窗口。如果 BAR 太小（比如 1MB），单次 DMA 读取的数据量受限，频繁发起 TLP 会增加延迟；如果 BAR 太大（比如 4GB），某些主板的 BIOS 会在 PCI 枚举时拒绝分配这么大的空间，导致设备无法识别。推荐的 BAR 配置是 256MB——足够大以支持批量读取，又不至于超出大多数主板的分配上限。

Speed Profile（速度档位）。部分 DMA 固件支持速度档位切换，本质是调整 PCIe 链路的 Lane 宽度和速率。35T 卡通常是 PCIe 2.0 x1（理论带宽 500MB/s），75T 和 100T 卡支持 PCIe 3.0 x4（理论带宽 ~4GB/s）。但实际有效带宽受 USB 3.0 接口限制——DMA 卡读取的数据最终要通过 USB 传到操作机，USB 3.0 实际带宽 ~400MB/s 是硬天花板。所以 PCIe 3.0 x4 的理论带宽再高也没有意义，除非你用双口板且两个 USB 口都连到操作机做带宽聚合。

踩坑记录：第一次用 DMA 卡时死活读不出数据，VmmInstance() 报 "device not found"。排查了半天发现是 DMA 卡插在了主板上的第二个 PCIe x16 插槽（物理 x16 但实际只走了 x4 信号），而这个插槽和显卡共享 Lane，插上 DMA 卡后显卡的 PCIe 降速了导致游戏卡顿。后来换到 PCIe x1 插槽（35T 卡只需要 x1），一切正常。教训：35T 卡插 x1 插槽，不要占 x16 插槽的 Lane，否则可能和显卡抢带宽。

选型总结：什么场景用什么方案

DMA 方案的本质是用硬件代价换取软件层不可见的内存访问能力。它比采集卡快三个数量级、比软件读取隐蔽三个数量级，但它不是银弹——固件配置的坑、偏移维护的成本、反作弊对抗的风险，每一项都是实打实的工程负担。采集卡方案胜在简单通用、跨平台、不依赖内存结构知识；DMA 方案胜在精度和速度。实际项目中最稳的做法是两条腿走路：DMA 做主力数据源，采集卡做视觉补充和降级兜底。哪条腿瘸了都还有另一条。