简介：尼康相机远程控制与二次开发套件，面向需在电脑端以桌面程序精确操控相机的开发者、摄影自动化实践者及具备一定C#或VB基础的中高级爱好者。资源围绕尼康SDK封装展开，提供C#与VB.NET示例，覆盖视频录制、连拍、单拍、手动对焦、相机能力查询等场景，并附WinForms与WPF演示工程，便于理解相机连接、参数设置、任务调度与图像处理接口的调用方式。压缩包共63个文件，约295KB，以31个C#源码、8个项目文件、6个VB源码及resx、settings、xaml、dll等为主，源码、工程配置与运行库齐全，目录按SDK封装、示例程序和测试应用组织，方便对照阅读和迁移到自有桌面项目。已有1334人学习，适合借此搭建可控拍摄、连拍采集与视频录制原型，也为自动化拍摄与图像处理流程提供可复用起点。
1. 相机连电脑这件事，SDK 才是分水岭
做产品图、做实验记录、做产线留档的开发，大概都碰过同一个场面：相机架在支架上，人守在旁边，一张一张按快门，一天下来手指发酸，图还容易漏。把 Nikon 相机连上电脑让它按程序触发，其实有两条路：一条是官方桌面工具，点点鼠标就能拍，但没法嵌进你自己的业务流程；另一条是 SDK，用代码调快门、调参数、拿原图。
这份资源走的是第二条。它给的是相机控制 SDK 本体，配 C# 封装和示例（还带 VB 版本可对照），覆盖单拍、连拍、实时取景这几项最常用的能力。适合谁：需要把拍摄动作塞进自动化流程的开发者——批量采集、定时序列、扫码联动拍照、视觉系统前端取图。只想远程点一下快门的话，官方工具更省事；但只要你要「拍完立刻进自己的程序」，SDK 就是分水岭。
2. 拿到压缩包先看什么：SDK 组件、示例工程与运行前置
很多人解开压缩包的第一反应是双击 sln，然后编译，然后报一堆错，然后开始怀疑资源有问题。这套 SDK 的包结构其实很规整，先花十分钟把「哪一层归哪一层」搞清楚，后面能省掉大半的调试时间。
2.1 包里其实是四类东西
拆开看，压缩包里通常混着四类内容，作用完全不同，别当成一个大工程对待。
| 类别 | 典型内容 | 你要不要动它 |
|---|---|---|
| 本机运行库 | 相机厂商提供的原生动态库（DLL） | 不动，只负责复制到输出目录 |
| 原生头文件 | C/C++ 头文件、枚举常量定义 | 不动，但它是唯一的「函数签名说明书」 |
| 托管封装 | C# 里对原生函数的 P/Invoke 声明与包装类 | 要动，这是你后续二次开发的主战场 |
| 示例工程 | 单拍、连拍、实时取景的控制台或窗体工程，C# 与 VB 各一份 | 先照抄，再改 |
原生库和头文件是厂商给的，别去反编译、别去打补丁；托管封装层是把 C 风格接口翻译成 C# 类的那一层，往往写得很朴素，一个函数对一个方法，没有状态机、没有重连、没有异常体系——这正是后面要动手改的地方。VB 示例的价值不在语言本身，而在于它和 C# 示例往往对应同一批 API 的两种调用顺序，遇到 C# 示例里某个参数含义不清时，拿 VB 那份对一遍经常能对上。
提示：先确认包里的示例是控制台工程还是 WinForms 工程。控制台工程跑通代表「链路通」，窗体工程跑通才代表「取流和界面刷新通」，两者失败原因完全不同，别混着查。
2.2 目录结构与工程引用关系
一个典型解压后的结构长这样（目录名各家会略有差异，按你手上的为准）：
sdk-package/ ├─ bin/ # 原生运行库，分 32 位与 64 位两套 │ ├─ x86/ # 老机型、老驱动常见落在这里 │ └─ x64/ ├─ include/ # 头文件与枚举定义，查函数签名就看这里 ├─ lib/ # 链接库，C# 用不上，C++ 示例才需要 ├─ dotnet/ # C# 托管封装工程 │ ├─ Native/NkNative.cs # P/Invoke 声明集中在这一层 │ ├─ CameraSession.cs # 会话包装：打开、拍摄、关闭 │ └─ Models/ # 参数枚举、返回码、异常类型 └─ samples/ ├─ cs/ # C# 示例：单拍 / 连拍 / 实时取景 └─ vb/ # VB 示例，用于对照调用顺序引用关系只有一条主线：示例工程引用托管封装工程，托管封装工程通过 P/Invoke 调用bin下的原生库。原生库不进 GAC，也不注册，全靠「和 exe 同目录」被找到。这一点决定了后面 80% 的启动失败都出在路径和位数上。
2.3 第一次跑通的前置条件
在改任何一行代码之前，把这四件事按顺序确认一遍，能挡掉绝大多数「代码没错但跑不起来」。
<!-- 示例工程 .csproj 里必须钉死平台，AnyCPU 是第一个坑 --> <PropertyGroup> <PlatformTarget>x64</PlatformTarget> <!-- 关掉 32 位首选，避免在 64 位系统上跑出 32 位进程 --> <Prefer32Bit>false</Prefer32Bit> <OutputPath>bin\Debug\</OutputPath> </PropertyGroup>PlatformTarget必须和bin下那份原生库的位数严格一致：给了 x64 的 DLL 却编出 32 位进程，表现出来就是一句「试图加载格式不正确的程序」，非常玄学，因为代码真的没错。Prefer32Bit是第二个坑，AnyCPU 工程在 64 位系统上默认可能仍以 32 位启动，把这个开关关掉，进程位数才和你以为的一致。
剩下三件事在系统层面：相机 USB 连接模式要切到 SDK 可控的那种（不少机身默认是存储/MTP 模式，此时 PC 只会把它当 U 盘，SDK 枚举不到设备）；拍摄前把厂商自带的桌面工具彻底退出，包括托盘图标，因为相机是独占资源，谁先连上谁占着；原生 DLL 必须复制到 exe 同目录，别指望它待在bin\x64子目录里被自动搜索到——Windows 的 DLL 搜索顺序里没有递归子目录这一条。
# 把原生库复制到输出目录，建议写进生成后事件，别手工复制 cp ./bin/x64/*.dll ./samples/cs/bin/Debug/写成生成后事件的好处是换机器、换分支、切 Debug/Release 都不会漏。手工复制一次的代价，往往是三天后同事拉代码跑不起来，然后花两小时排查一个「文件没拷」。
3. 核心链路拆解：从打开相机会话到单拍落盘
整条链路的真实形状是一条直线加一个回调：打开会话 → 配置参数 → 触发快门 → 等回调把图送回来 → 落盘 → 关闭会话。连拍是这条直线的循环，实时取景是把它换成一个取帧循环。理解了单拍，剩下两个都是变体。
3.1 相机枚举与会话建立
托管封装层的起点就是 P/Invoke 声明。下面这段是典型写法，函数名和 DLL 名按占位处理，实际值以包里头文件为准。
// NkNative.cs —— 对 SDK 原生导出函数的薄封装 // DllName 用包里实际的原生库名替换，不同版本命名不一致 internal static class NkNative { private const string Dll = "NikonSdk"; // 占位名，换成 bin 下真实文件名（不含 .dll） // 打开第 index 台相机；handle 是出参，后续所有调用都靠它 [DllImport(Dll, CallingConvention = CallingConvention.StdCall)] internal static extern int NkOpenCamera(int index, out IntPtr handle); // 关闭会话，必须和 NkOpenCamera 成对出现，异常路径也要走到 [DllImport(Dll, CallingConvention = CallingConvention.StdCall)] internal static extern int NkCloseCamera(IntPtr handle); // 触发一次快门，shotSeq 是本次拍摄序号，用于和回调里的图对上号 [DllImport(Dll, CallingConvention = CallingConvention.StdCall)] internal static extern int NkCapture(IntPtr handle, int shotSeq); // 设置属性（ISO、快门、光圈等），propId 取值见头文件枚举 [DllImport(Dll, CallingConvention = CallingConvention.StdCall)] internal static extern int NkSetProperty(IntPtr handle, int propId, double value); }CallingConvention.StdCall不能省，C# 默认是 Winapi，在 x86 下运气好能对上，切到 x64 后调用约定差异被抹平，问题反而藏得更深，等到换机型才炸。out IntPtr把原生句柄接出来，务必当成不透明值对待，不要做算术、不要跨线程乱传。所有函数返回int返回码，0 表示成功，非 0 是错误码——这套 API 不抛异常，异常得你自己在包装层造出来。
public sealed class CameraSession : IDisposable { private IntPtr _handle = IntPtr.Zero; private readonly object _gate = new object(); // 相机是独占资源，串行化是底线 private int _seq; public bool IsOpen => _handle != IntPtr.Zero; public void Open(int index = 0) { if (IsOpen) return; int rc = NkNative.NkOpenCamera(index, out var h); if (rc != 0) throw new CameraException(rc, "打开相机失败"); _handle = h; } public void SetIso(double iso) { // propId 从 header 里的属性枚举取，别硬编码数字 int rc = NkNative.NkSetProperty(_handle, PropId.Iso, iso); if (rc != 0) throw new CameraException(rc, "设置 ISO 失败"); } public void Dispose() { if (!IsOpen) return; NkNative.NkCloseCamera(_handle); _handle = IntPtr.Zero; } }_gate这个锁不是防御性编程，是必需的：相机的控制通道是单会话的，UI 线程在主拍、定时器在调参数、后台在取帧，三路并发下去，轻则参数互踩，重则原生层直接崩，而且崩在 C 代码里，连堆栈都看不清。CameraException把错误码包一层，方便在日志里统一格式化，排查时看到rc=0x8201比看到「操作失败」有用一百倍。
3.2 单拍：一次完整的「参数-快门-取图」流程
单拍最容易写错的地方不是拍，是「等图」。触发快门只是把指令发出去，图像是异步回来的，回调可能来自 SDK 自己的线程。所以需要一个按序号匹配的收件箱。
// 按序号收图的信箱：触发和取图分属两个线程，靠 seq 对齐 private readonly ConcurrentDictionary<int, TaskCompletionSource<byte[]>> _pending = new(); private readonly ConcurrentDictionary<int, byte[]> _arrived = new(); // SDK 回调里调用：别在这里做落盘、别碰 UI internal void OnImageReady(int seq, byte[] jpeg) { if (!_pending.TryRemove(seq, out var tcs)) { _arrived[seq] = jpeg; return; } tcs.TrySetResult(jpeg); // 没人在等就先存着，防止竞态丢图 } public byte[] CaptureOnce(int timeoutMs = 8000) { lock (_gate) { int seq = Interlocked.Increment(ref _seq); if (_arrived.TryRemove(seq, out var early)) return early; var tcs = new TaskCompletionSource<byte[]>(TaskCreationOptions.RunContinuationsAsynchronously); _pending[seq] = tcs; int rc = NkNative.NkCapture(_handle, seq); if (rc != 0) { _pending.TryRemove(seq, out _); throw new CameraException(rc, "触发快门失败"); } // 超时是必需的：相机没对焦、卡没插、机身忙，都会让回调永远不来 if (!tcs.Task.Wait(timeoutMs)) { _pending.TryRemove(seq, out _); throw new TimeoutException($"第 {seq} 张在 {timeoutMs}ms 内没有回图"); } return tcs.Task.Result; } }RunContinuationsAsynchronously这个标志需要说明：不加它，TrySetResult会同步执行后续的续体，也就是在 SDK 的回调线程上跑你的落盘代码，一旦落盘慢一点，回调就堵住，SDK 侧缓冲被占满，表现为「拍三张以后就再也不回图」。这是很典型的一处坑，症状和死锁几乎一样。
_arrived是为竞态准备的兜底：有些机型回调极快，NkCapture还没返回，图就已经送回来了，此时_pending里还没有对应的tcs，图就被丢掉了。先存后取，虽然用字典做小缓冲有点简陋，但它比加锁等回调的写法稳得多。
timeoutMs默认给 8 秒，是因为单反/微单从触发到对焦完成、再回一张全尺寸 JPEG，慢的时候三四秒是常事；如果是弱光、镜头在拉风箱，再翻一倍也正常。超时后必须把_pending里那条清掉，否则残留的tcs会在某次序号复用时造成错配——这类 bug 的复现周期以小时计，非常折磨人。
3.3 连拍：定时器、周期扣除与缓冲队列
连拍有两种实现思路：一种是用机身的连拍模式，一次触发连续出图；另一种是软件侧定时循环触发单拍。示例里给的多半是后者，因为它对机型依赖小、间隔可控、每张都能带独立参数。写循环的时候有两个细节必须处理。
// 间隔连拍：间隔指「拍摄周期」，不是「拍完之后再等这么久」 public async Task BurstAsync(int count, int intervalMs, Action<byte[], int> onFrame, CancellationToken ct) { for (int i = 0; i < count && !ct.IsCancellationRequested; i++) { var sw = Stopwatch.StartNew(); byte[] jpeg; try { jpeg = CaptureOnce(); } catch (TimeoutException) { continue; } // 单张超时不终止整组，记日志继续 onFrame?.Invoke(jpeg, i); // 交给上层异步落盘，别在这里写盘 int rest = intervalMs - (int)sw.ElapsedMilliseconds; if (rest > 0) await Task.Delay(rest, ct).ConfigureAwait(false); } }第一个细节是周期扣除：如果intervalMs是 2000，而拍摄本身花了 800ms，那么真正的间隔应该是再等 1200ms，不是再等 2000ms。不扣的话，实际周期会变成 2800ms，节拍器应用里这个误差会一直累积，最后序列时间戳全歪。
第二个细节是下限。软件定时连拍的最小间隔并不由你的Task.Delay决定，而是由相机写卡、机身缓冲、图像传输三者里最慢的那个决定。不同机型这个下限差得很多，高端机身可能 300ms 就能稳定出图，入门机身 800ms 之后才开始丢帧。调参的时候从 1500ms 往下试，出现超时或丢图就退回去一档，比看参数表猜要靠谱。
onFrame回调里别直接File.WriteAllBytes。写盘是毫秒级到几十毫秒级的抖动操作，写在拍摄循环里会直接污染节拍。常见做法是丢进Channel<byte[]>或者BlockingCollection，由单独一个写盘线程消费，队列长度设上限（比如 8），满了就丢最旧的并记一条警告——拍摄现场丢掉旧帧，比把整条链路拖死要好。
另外，每张图都要带上下文：序号、触发时间、当时的参数快照。落盘文件名建议直接把这些信息编进去，例如20240512_143002_017_iso400.jpg。等到后期要拿这组图做延时合成，或者要核对某张参数是不是记错了，文件名就是唯一可靠的黑匣子。
4. 实时取景叫「视频」：Live View 取流、转码与保存
示例里说的「视频」，绝大多数情况下不是指录像文件，而是实时取景（Live View）——相机把传感器的预览画面以低分辨率 JPEG 帧的形式连续吐给 PC。理解这一点很关键：拿到的是帧序列，不是封装好的视频流，想变成 mp4 得自己做封装或编码。
4.1 取流循环：只传引用，以及为什么必须独立线程
取流是整篇文章里最容易把程序写崩的一环，因为它的节奏和 UI 完全不是一个数量级：一秒钟二十到三十帧，每帧几十到几百 KB，任何一次多余的分配都会在几分钟内累积成一次 GC 停顿，然后画面卡住、帧积压、内存上涨。
private Thread _lvThread; private CancellationTokenSource _lvCts; public void StartLiveView() { _lvCts = new CancellationTokenSource(); // 独立线程，且明确设为后台线程，主窗口关掉时能干净退出 _lvThread = new Thread(() => LiveViewLoop(_lvCts.Token)) { IsBackground = true, Name = "lv-grab" }; _lvThread.Start(); } private void LiveViewLoop(CancellationToken ct) { // 按最大可能尺寸申请一次，之后整个生命周期复用这一块 var buf = new byte[1920 * 1080 * 3]; int size = buf.Length; while (!ct.IsCancellationRequested) { int rc = NkNative.NkGetLiveViewFrame(_handle, buf, ref size); if (rc != 0) { // 没有新帧是常态（相机帧率低于你的轮询速度），退让而不是空转 Thread.Sleep(15); size = buf.Length; // 失败时 size 可能被改坏，重置回去 continue; } OnFrame?.Invoke(buf, size); // 只传引用，拷贝交给下游决定 Thread.Sleep(1); } }size是进出参这一点要特别注意：进是缓冲区容量，出是这一帧的实际字节数。失败路径上 SDK 有可能把size写成一个无意义的值，不重置的话下一轮传进去的容量就是错的，接着就是「数组越界」或者「缓冲区不足」来回跳。这个坑我在别的采集 SDK 上也踩过，属于通用血泪经验。
缓冲区复用带来一个新问题：OnFrame拿到的是同一块内存的引用，下游如果异步处理，等它处理时数据早就被下一帧覆盖了。所以下游要么当场转成不可变对象（比如new Bitmap），要么显式拷贝一段byte[]。别在这个位置心疼一次拷贝，心疼的代价是花屏，而花屏是那种「偶发、截图截不到、客户现场必现」的问题。
4.2 JPEG 帧转 Bitmap 与双缓冲显示
取到的帧通常是 JPEG 字节流，转成Bitmap一行就够，但这一行有陷阱。
private Bitmap _back; // 后台线程只写它 private readonly object _bmpGate = new object(); private void OnFrame(byte[] data, int len) { try { using var ms = new MemoryStream(data, 0, len, writable: false); using var tmp = new Bitmap(ms); // 直接吃 JPEG 字节流 var bmp = new Bitmap(tmp); // 关键：脱开流，复制一份独立位图 lock (_bmpGate) { _back?.Dispose(); _back = bmp; } _ui.Invalidate(); // 只标脏，真正绘制交回 UI 线程 } catch (ArgumentException) { // 帧不完整（相机切模式、USB 抖动）时 GDI+ 会抛，丢掉这一帧即可 } } private void OnPaint(object s, PaintEventArgs e) { lock (_bmpGate) { if (_back == null) return; e.Graphics.InterpolationMode = InterpolationMode.Bilinear; e.Graphics.DrawImage(_back, 0, 0, _view.Width, _view.Height); } }new Bitmap(tmp)这一行不能省。Bitmap(Stream)构造出来的位图会持有那个流，ms一旦被using释放，后续绘制就会抛ArgumentException或者画出红叉。这个现象很迷惑：代码看着完全正常，图有时候能显示、有时候不能，因为 GDI+ 是延迟读取的，取决于 GC 什么时候真的回收了那块内存。
Invalidate而不是直接DrawImage，是为了把绘制压回 UI 线程。Invalidate只是标脏，系统会合并多次请求，天然做了节流；如果画面刷新跟不上 25fps，它也不会排队堆积。
_back的替换用lock加Dispose旧图，这两步必须在一起。只替换不释放，几万帧之后就是内存稳步上涨；只释放不替换，UI 线程正在DrawImage时就撞上已释放对象，抛ArgumentException或者直接崩在 GDI+ 内部。
4.3 把帧序列写成视频文件
如果确实要出视频文件（延时、过程记录），思路是把帧序列按固定 fps 编码。示例包里一般只给到「保存为连续 JPEG」，编码这一步得自己接。
// 实时取景帧率不稳，写入时按固定 fps 打时间戳，避免播放速度漂移 using OpenCvSharp; using var writer = new VideoWriter("live.avi", FourCC.MJPG, 25, new Size(1280, 720)); // ...在取帧回调里： using var mat = Cv2.ImDecode(new Mat(1, len, MatType.CV_8UC1, data), ImreadModes.Color); if (mat.Empty()) return; // 残帧直接丢 if (mat.Width() != 1280 || mat.Height() != 720) Cv2.Resize(mat, mat, new Size(1280, 720)); // 尺寸必须和 writer 一致 writer.Write(mat);VideoWriter的尺寸参数必须和每一帧的尺寸严格一致，不一致直接静默丢帧，Write返回 false 但不抛异常，很容易以为在录、其实文件是空的。方案里要么在构造时就按取流分辨率定死，要么在写入前统一Resize，别指望它帮你适配。
FourCC.MJPG是个务实的选择：JPEG 本来就是取景帧的原始格式，用 MJPEG 编码几乎不用做像素转换，CPU 占用低。要出 H.264 就得引入外部编码器，多一层依赖，在采集端这种「稳定优先」的场景里不太划算。真需要压缩率，规范做法是采集端只存 JPEG 序列加一份时间戳 CSV，事后离线批量转码，把编码压力和采集稳定性彻底解耦。
5. 避坑与排查：连接、位数、超时、资源释放
这一章的五条，基本覆盖了这套 SDK 上手一周内会撞到的全部问题。每一条都按「现象 → 原因 → 解决」写，方便你直接对照排查。
5.1 连不上、打不开、枚举不到
现象一：示例工程编译通过，一运行就报「无法加载 DLL 'NikonSdk' 或其依赖项之一」，换台机器又好了。
原因：两类，一是原生库没复制到 exe 同目录，二是进程位数和 DLL 位数不匹配。第二种尤其阴，错误信息里也提到「格式不正确」，很多人误以为是 DLL 坏了。
解决：先用任务管理器确认进程是 32 位还是 64 位，再看bin下拿的是哪一份。把PlatformTarget钉死，原生库复制写成生成后事件，两件事同时做，别只做一件。
现象二：NkOpenCamera返回非 0，错误码查头文件是「设备未找到」，但相机明明插着，设备管理器里也能看到。
原因：相机处在存储/MTP 模式，PC 把它当移动盘；或者厂商桌面工具还在后台连着相机，独占资源被占。
解决：机身菜单里把 USB 模式切到 SDK 可控项，退出所有官方工具（含托盘图标），必要时拔插一次 USB 让系统重新枚举。设备管理器里能看到设备，只说明 USB 枚举成功，不代表 SDK 拿到了控制权，这两件事要分开判断。
现象三：NkOpenCamera成功，但图像回调一次都不触发。
原因：回调注册时机不对。有的 SDK 要求先注册回调再NkOpenCamera，有的要求打开之后再注册，示例里怎么写的就怎么来，别凭感觉调顺序。另一种可能是回调依赖消息泵，在控制台程序里跑窗体工程的逻辑，回调永远等不到。
解决：对照包里的 C# 和 VB 两份示例，看回调注册在Open之前还是之后；控制台场景改用窗体或显式跑消息循环。
5.2 跑一会儿才出问题的那些
现象四：连续拍几十张以后卡死，或者程序自己退出，事件日志里没有有用的堆栈。
原因：原生句柄和缓冲区没释放，累积到 SDK 内部上限就拒绝服务；或者阻塞式调用被放在了 UI 线程上，界面假死之后用户强杀，看起来像「程序崩了」。
解决：CameraSession一律IDisposable，所有原生资源用using包住；拍摄、取流全部丢后台线程，UI 线程只做显示。加一条自检：连续拍 200 张不重启，看内存曲线是否平坦，不平坦就是有泄漏。
现象五：拔插 USB 或相机自动休眠后，程序不恢复，后续所有调用都失败。
原因：_handle已经失效，但代码里还是IsOpen == true，一路拿着野句柄调下去。
解决：加心跳。每隔几秒做一次轻量的属性读取，连续失败两次就判定断线，把会话置为关闭、释放资源，然后按退避策略重连（1s、2s、5s、10s 封顶）。重连成功后要重建参数，相机断线后参数会回落到机身默认值，这个不重设，拍出来的图曝光会突然差一截。
注意：排查这类间歇性问题时，日志里一定要带上返回码和耗时。只写「拍摄失败」的日志等于没有日志，因为你能拿到的唯一线索就是那个码。
6. 二次开发改造：把示例代码变成能跑一整天的采集服务
示例工程的定位是「演示 API 怎么调」，不是「能上线跑」。两者之间差的不是功能，是状态管理。我一般做的第一件事，是把散落在事件处理函数里的调用收敛成一个显式状态机：Disconnected → Connecting → Ready → Capturing → Error，任何一次 API 调用前先断言当前状态，非法转移直接抛，而不是让它在原生层里以错误码的形式飘出来。状态机加完之后，那些「偶发卡死」的问题会立刻变成「有明确堆栈的异常」，排查成本降一个数量级。
第二件事是把配置外置。拍摄间隔、连拍张数、ISO、超时、保存路径、是否开启取景，全部挪到一份 JSON 里，程序启动读一次，改参数不用重新编译。特别是超时值，不同机型差得太多，写死在代码里意味着换一台机身就要改代码发版。
| 改造点 | 改之前 | 改之后 | 验证方式 |
|---|---|---|---|
| 会话生命周期 | 打开后一直用 | 心跳 + 状态机 + 退避重连 | 手动拔插 USB 十次，观察是否自愈 |
| 落盘 | 回调里直接写文件 | 有界队列 + 独立写盘线程 | 拍摄间隔调到 500ms，看是否丢帧 |
| 参数 | 硬编码 | JSON 配置 + 启动加载 | 改配置重启，对比 EXIF |
| 显示 | 直接 DrawImage | 双缓冲 + Invalidate 节流 | 连续取景 1 小时，看 CPU 与内存 |
第三件事是准备两套验证环境。一套是假相机：把CameraSession抽成接口，写一个FakeSession按固定节拍返回本地 JPEG 文件，跑逻辑和压力测试时用它，不用占着真机。另一套是真机长稳：连续采集两小时以上，中途故意拔一次 USB、故意让相机休眠一次，最后核对图片数量和序号是否连续——序号断档就是丢图，丢图必然有对应的日志，顺着日志往回找，基本都能定位到是超时还是队列溢出。这套假相机 + 真机长稳的组合，我后来做任何硬件采集类项目都会先搭起来，因为省下来的时间远超搭它的时间。
还有一个容易被忽略的技巧：把「取图」和「存图」的契约从byte[]改成只读的ReadOnlyMemory<byte>加一个序号和时间戳，中间层谁都不能偷偷改缓冲区。这个改动很小，但它逼着你在设计阶段就想清楚「这块内存归谁」，后面再也不会出现下游异步处理拿到被覆盖数据的花屏问题。从那以后我每次接相机、扫码枪、采集卡这类 SDK，都会先把回调线程模型和缓冲所有权在纸上画一遍，再动手写第一行代码，希望帮到你。
本文还有配套的精品资源，点击获取
