佳能EDSDK C#开发实战：相机自动化控制从初始化到成片全流程-北京尧图网络

简介佳能EDSDK的C#完整开发示例面向需要在.NET平台联机控制佳能相机的C#开发者覆盖设备管理、实时预览、远程拍摄、图像下载与事件处理等核心场景。资源共18个文件以8个C#源代码文件为主包含主窗体实现、相机操作类与核心接口封装同时提供项目工程文件、resx资源文件、配置及3个说明文档压缩包整体仅73KB便于快速下载与研读。示例代码从初始化加载动态库、枚举相机设备、建立会话、获取快门光圈等属性到发送指令完成拍照与下载图像完整呈现了EDSDK的核心调用链事件回调与资源释放也有标准写法可参考。目前已有1021人学习浏览适合新手快速搭建可运行的相机控制项目也为自动化拍摄、远程监控等二次开发提供了可扩展的基础。1. 佳能EDSDK C# 完整开发示例从相机开关到成片的自动化控制做自动拍摄系统的开发者十有八九会在某个夜里盯着一台连上USB却完全不受控的相机发愁驱动装了、线也接了可在 C# 程序里就是发不出拍摄指令、拿不到取景画面、回调一个都不触发。佳能EDSDKEOS Digital SDK就是那个黑匣子的钥匙——它是佳能官方提供的原生 C/C SDK负责在 PC 端控制相机的开机、拍摄、取景、参数调节和照片下载。问题在于大多数产线程序、影棚自动化软件和内部质检工具都是用 C# 写的要让原生 SDK 和 .NET 世界对话就得靠 P/Invoke 把 DllImport 声明、事件回调和对象生命周期全部接管过来。这篇笔记按我做过的完整流程来写从 SDK 目录结构和最小初始化到实时取景、拍照下载再到回调线程、内存泄漏这些躲不开的坑最后落到一个能交付的状态机设计。适合三类人写批量拍摄设备程序的工程开发者、做影棚自动化系统的桌面端以及想为内部项目引入相机控制的新手。2. 环境准备与 P/Invoke 边界先把 SDK 目录和 DLL 调用理清楚2.1 SDK 目录结构哪个 DLL 才是 C# 要面对的佳能官方分发的 EDSDK 压缩包解开之后典型结构是 Dll、Inc、Samples 三大块。Dll 目录下是真正的原生动态库Inc 目录放着头文件Samples 目录里是 C 和 C 的参考工程。对 C# 开发者来说真正干活的是 Dll 目录下的 EDSDK.dll它没有 COM 注册、没有 .NET 包装只暴露纯 C 接口C# 端必须通过 DllImport 逐函数声明入口。这里第一个常见的翻车点就出现了EDSDK.dll 的位数必须和 C# 程序集的目标平台一致。很多人在 64 位系统上把工程设为 AnyCPU运行时却说找不到 DLL 入口其实是因为 AnyCPU 在 64 位进程里加载 64 位 DLL而你手头的 EDSDK.dll 若是 32 位版本必然加载失败。我一般会把整个开发机统一成 x64项目属性里目标平台显式选 x64SDK 也取 64 位那套避免这种玄学问题反复纠缠。另一个容易忽略的点是EDSDK 不是绿色 DLL它内部会调用相机的系统驱动层。装机之后最好先把官方控制软件跑一遍确认相机能被系统识别了再动代码。跳过这步后面查枚举不到相机的问题会多绕两三个小时而且很容易误判成代码问题。2.2 C# 封装的三层结构NativeMethods、封装层、业务层我在项目里不把 DllImport 散落到业务代码中。常见做法是分三层第一层是 EdsNativeMethods原样声明 EDSDK 的 C 函数只做签名映射不做任何逻辑第二层是 EdsSession 封装类把相机句柄、会话状态、回调委托都收进来对外暴露 Connect、TakePicture、StartLiveView 这类方法第三层才轮到业务层写状态机和流程控制。这样分层的好处很实际SDK 升级时只改第一层回调线程问题只改第二层上位机的拍摄流程写起来干净得多。我在模拟项目 X 里就是按这套结构组织的代码后面所有示例代码也都按这个分层给出。新手容易犯的错误是图省事直接在窗体代码里写 DllImport结果一个窗体关掉SDK 状态全乱再开第二个窗体就没法工作了。封装层还需要考虑一个全局性约束EdsInitializeSDK 和 EdsTerminateSDK 必须成对出现且全局唯一。如果你的程序有多个窗体千万不要每个窗体都初始化一遍又终止一遍。初始化和终止放程序入口和退出出口中间任何窗体都只复用同一个封装实例。2.3 最小初始化与相机枚举三段代码跑通看得见相机先看 NativeMethods 层的最小声明internal static class EdsNativeMethods { public const uint EDS_ERR_OK 0x00000000; [DllImport(EDSDK.dll, EntryPoint EdsInitializeSDK)] internal static extern uint EdsInitializeSDK(); [DllImport(EDSDK.dll, EntryPoint EdsTerminateSDK)] internal static extern uint EdsTerminateSDK(); [DllImport(EDSDK.dll, EntryPoint EdsGetCameraList)] internal static extern uint EdsGetCameraList(out IntPtr cameraList); [DllImport(EDSDK.dll, EntryPoint EdsGetChildCount)] internal static extern uint EdsGetChildCount(IntPtr list, out int count); [DllImport(EDSDK.dll, EntryPoint EdsGetChildAtIndex)] internal static extern uint EdsGetChildAtIndex(IntPtr list, int index, out IntPtr camera); [DllImport(EDSDK.dll, EntryPoint EdsRelease)] internal static extern uint EdsRelease(IntPtr obj); }这段声明的关键点有三个。一是所有返回类型都统一用 uint 承载 EdsError不要为了好看改成 intSDK 的错误码范围比你想的大签名不一致会导致错误码错位排查时看到的值根本不是真实返回。二是凡是 SDK 返回的对象句柄用完都必须调 EdsRelease这是内存泄漏的第一源头。三是 EntryPoint 明确写函数名避免 C# 默认的命名修整在 Debug 和 Release 切换时出怪问题。接着写最小枚举流程uint err EdsNativeMethods.EdsInitializeSDK(); if (err ! EdsNativeMethods.EDS_ERR_OK) { throw new InvalidOperationException($SDK初始化失败错误码0x{err:X8}); } IntPtr cameraList IntPtr.Zero; try { err EdsNativeMethods.EdsGetCameraList(out cameraList); if (err ! EdsNativeMethods.EDS_ERR_OK) { throw new InvalidOperationException($获取相机列表失败错误码0x{err:X8}); } int count 0; EdsNativeMethods.EdsGetChildCount(cameraList, out count); Console.WriteLine($检测到 {count} 台相机); for (int i 0; i count; i) { IntPtr camera IntPtr.Zero; EdsNativeMethods.EdsGetChildAtIndex(cameraList, i, out camera); Console.WriteLine($相机索引 {i}句柄 0x{camera.ToInt64():X}); } } finally { if (cameraList ! IntPtr.Zero) { EdsNativeMethods.EdsRelease(cameraList); } EdsNativeMethods.EdsTerminateSDK(); }这段代码里有三个细节值得单独说。第一EdsGetCameraList 返回的列表本身也是一个需要释放的 SDK 对象很多人枚举完相机就忘了释放它程序跑半天句柄数就上去了。第二EdsGetChildAtIndex 拿到的相机句柄在这个最小示例里只是打印如果你后面要打开会话、注册回调就必须保存这个句柄并在整个生命周期结束时释放只打印、不继续用原则上可以把释放延后但我会养成只要拿到句柄就记入一个统一释放列表的习惯。第三finally 块里先释放列表再终止 SDK顺序不要反否则 SDK 内部还在引用列表可能释放失败。到这里C# 已经能和 EDSDK 对上话了。下一步就是把它变成真正能拍片的会话这时才开始碰核心的事件和回调机制。3. 相机会话与实时取景把黑匣子变成看得见的画面3.1 打开会话为什么必须执行 EdsOpenSession枚举到相机句柄只是第一步。EDSDK 把能访问相机和能控制相机分成两个状态分界线就是 EdsOpenSession。没有打开会话时SDK 只允许你查设备信息打开会话之后才允许下发拍摄命令、注册事件回调、访问和修改相机属性。这个设计很像文件系统的句柄机制你要先拿到一个有效会话后续所有操作才有上下文。public void Connect(IntPtr camera) { _camera camera; uint err EdsNativeMethods.EdsOpenSession(_camera); if (err ! EdsNativeMethods.EDS_ERR_OK) { throw new InvalidOperationException($打开相机会话失败错误码0x{err:X8}); } _sessionOpen true; }这段调用有个隐藏的细节EdsOpenSession 执行期间SDK 会尝试与相机建立稳定连接。如果相机之前被别的软件占用这步会直接返回设备忙的错误码。所以我在实际开发中点连接按钮之前先做一次占用检查把占用冲突和连接失败两种错误分开提示否则一线操作员根本不知道要先去关掉另一个软件只会反复点按钮。与打开相对的是 EdsCloseSession这步在断开连接时必须调用。很多人直接拔 USB 线跳过 SDK 的清理逻辑轻则下次连接枚举不到相机重则相机端协议栈异常需要重启相机。我的习惯是拔线之前先走一次 CloseSession再 Release 相机句柄最后才允许物理断开。3.2 注册事件回调EDSDK 通知机制的基本盘EDSDK 不是轮询接口它靠回调通知上层状态事件、属性事件、对象事件、进度事件。C# 里要注册回调得按 SDK 头文件里的委托签名来声明public delegate uint EdsObjectEventHandler( uint inEvent, IntPtr inRef, IntPtr inContext); public delegate uint EdsPropertyEventHandler( uint inEvent, uint inPropertyId, uint inParam, IntPtr inContext); public delegate uint EdsStateEventHandler( uint inEvent, uint inParam, IntPtr inContext);注册的代码是[DllImport(EDSDK.dll, EntryPoint EdsSetObjectEventHandler)] internal static extern uint EdsSetObjectEventHandler( IntPtr camera, uint inEvent, EdsObjectEventHandler handler, IntPtr inContext); [DllImport(EDSDK.dll, EntryPoint EdsSetPropertyEventHandler)] internal static extern uint EdsSetPropertyEventHandler( IntPtr camera, uint inEvent, EdsPropertyEventHandler handler, IntPtr inContext); [DllImport(EDSDK.dll, EntryPoint EdsSetStateEventHandler)] internal static extern uint EdsSetStateEventHandler( IntPtr camera, uint inEvent, EdsStateEventHandler handler, IntPtr inContext);封装层调用时最需要注意的一件事是委托对象的生命周期// 用字段持有委托防止被GC回收 private EdsObjectEventHandler _objectHandler; private EdsPropertyEventHandler _propertyHandler; private EdsStateEventHandler _stateHandler; public void RegisterCallbacks() { _objectHandler OnObjectEvent; _propertyHandler OnPropertyEvent; _stateHandler OnStateEvent; EdsNativeMethods.EdsSetObjectEventHandler( _camera, 0x00000100 /* kEdsObjectEvent_All */, _objectHandler, IntPtr.Zero); EdsNativeMethods.EdsSetPropertyEventHandler( _camera, 0x00000100 /* kEdsPropertyEvent_All */, _propertyHandler, IntPtr.Zero); EdsNativeMethods.EdsSetStateEventHandler( _camera, 0x00000100 /* kEdsStateEvent_All */, _stateHandler, IntPtr.Zero); }这里必须用类字段把三个委托实例牢牢引用住。委托是托管的如果不持有引用GC 一压缩回调就被回收现象就是相机操作正常但事件一个都不来。这是 EDSDK C# 开发里最阴间的坑之一明明注册了却像没有注册一样。回调函数里要处理的第二件事是线程。EDSDK 的回调跑在 SDK 自己的工作线程上不是 UI 线程。你在回调里直接操作 TextBox 或 RichTextBox马上会撞上跨线程异常。常见做法是把事件消息塞进 ConcurrentQueueUI 线程定时批量取走或者用 Dispatcher 切回 UI 线程。我偏好队列方案因为回调频率高的时候直接 Invoke 会把界面卡成慢动作队列配合定时器可以限流稳定性好很多。3.3 实时取景与参数设置三个高频 API实时取景是 EDSDK 上最常被问到的功能。整体流程分三步创建 Evf 数据区、发送 Evf 开启命令、循环取帧public IntPtr CreateEvfData() { IntPtr evfData IntPtr.Zero; uint err EdsNativeMethods.EdsCreateEvfData(out evfData); if (err ! EdsNativeMethods.EDS_ERR_OK) { throw new InvalidOperationException($创建Evf数据区失败错误码0x{err:X8}); } _evfData evfData; return evfData; } public void StartLiveView() { // kEdsCameraCommand_Evf 2参数 start 1 uint err EdsNativeMethods.EdsSendCommand( _camera, 2, (IntPtr)1); if (err ! EdsNativeMethods.EDS_ERR_OK) { throw new InvalidOperationException($开启实时取景失败错误码0x{err:X8}); } } public IntPtr GrabLiveViewFrame() { IntPtr image IntPtr.Zero; uint err EdsNativeMethods.EdsGetEvfImage(_evfData, out image); if (err ! EdsNativeMethods.EDS_ERR_OK) { return IntPtr.Zero; } return image; }这段代码的要点是EdsGetEvfImage 返回的是一个图像对象你还需要再调用读取接口把它转成字节数组才能显示成 Bitmap。实时取景的帧数据本质是 JPEG很多开发者以为拿到的是原始 RGB直接拿去做二次开发结果发现颜色偏到没法看就是没意识到数据是压缩编码需要先解码再处理。参数设置走的是 EdsSetPropertyData最常用的三组是 ISO、光圈、快门public void SetIso(uint isoValue) { // kEdsPropID_ISOSpeed 0x00000010 uint err EdsNativeMethods.EdsSetPropertyData( _camera, 0x00000010, 0, 4, ref isoValue); if (err ! EdsNativeMethods.EDS_ERR_OK) { throw new InvalidOperationException($设置ISO失败错误码0x{err:X8}); } }这里要特别提醒属性写入的生效条件依赖相机状态。比如光圈在自动档下可能写进去了但不生效因为相机逻辑认为当前模式不允许你手动指定光圈快门速度在 M 档和 Tv 档才能自由指定。血泪经验是每次设置前先读当前拍摄模式模式不对先切换模式再写属性写完还要回读一次确认否则你以为参数生效了实际拍出来是另一套参数。4. 拍摄命令与照片下载按下快门到本地成片的全链路4.1 发送拍摄命令异步事件等待的智慧拍摄动作本身只是一个 EdsSendCommand但在真实产线里按下快门只是整个链路的第一环。你需要处理的是相机何时拍完、照片何时可下载、下载何时结束这三个异步节点。public void TakePicture() { // kEdsCameraCommand_TakePicture 0 uint err EdsNativeMethods.EdsSendCommand(_camera, 0, IntPtr.Zero); if (err ! EdsNativeMethods.EDS_ERR_OK) { throw new InvalidOperationException($发送拍摄指令失败错误码0x{err:X8}); } }在 EDSDK 的事件模型里这个拍摄命令不是阻塞调用。相机执行拍摄后会通过对象事件回调抛出新照片文件产生的事件。所以正确流程是先把对象事件回调注册好再发拍摄命令然后在回调里接收事件再做下载。这个先注册再发命令的顺序相当重要。如果你先拍了再注册回调中间那个事件已经过去了照片文件会以未消费的状态堆积在相机缓存里而你一个回调都收不到。我在做某跨平台系统时这个问题导致首单拍照后界面卡了两秒无响应查了半天才发现是事件没接住。4.2 下载照片到本地处理好相机目录对象拿到对象事件之后回调参数里的 inRef 就是照片的目录项对象。把它转成文件引用再调用下载接口private uint OnObjectEvent(uint inEvent, IntPtr inRef, IntPtr inContext) { // kEdsObjectEvent_DirItemCreated 0x00000202 if (inEvent 0x00000202) { IntPtr fileRef IntPtr.Zero; // kEdsAccess_Read 0 EdsNativeMethods.EdsCreateFileRef(inRef, 0, out fileRef); string fileName ReadFileName(fileRef); string savePath Path.Combine(_saveDirectory, fileName); uint err EdsNativeMethods.EdsDownload( fileRef, savePath, 0); if (err EdsNativeMethods.EDS_ERR_OK) { // 通知相机该目录项已处理完毕 EdsNativeMethods.EdsDownloadComplete(fileRef); } if (fileRef ! IntPtr.Zero) { EdsNativeMethods.EdsRelease(fileRef); } } return 0; }注意EdsDownload 完成只代表 PC 端文件写完了EdsDownloadComplete 是通知相机端清理缓存两层含义别混用。这段代码里最容易被忽略的是 EdsDownloadComplete。下载完成之后不调这个接口相机会认为文件还没被取走继续在缓存中保留短时间内没事但连续拍几百张之后相机端缓存会满轻则拍摄变慢重则直接拒绝拍摄。这个坑的印象很深有次批量测试跑到第 437 张停住了就是少了这句。另外文件名不能自己乱拼。EDSDK 的文件名是相机固件定的正确做法是从目录项里读取文件名属性拼上扩展名。手动拼接的结果往往是找不到文件尤其当你同时拍 JPG 和 RAW 时同一张照片会生成两个不同的目录项各有各的命名规则。4.3 断线重连与状态检查完整的状态机设计下载链路稳定之后整个拍摄流程的骨架就清楚了。我一般会这样组织状态机enum CameraState { Idle, // 未连接 Connecting, // 正在连接 Ready, // 已就绪可拍摄 Shooting, // 已发送拍摄命令等待事件 Downloading,// 正在下载照片 Reconnecting // 断线重连中 }每拍一张先把当前事件序号记下来发送拍摄命令后等待对应事件回调。如果超过设定超时时间还没等到就触发一次状态查询先看看相机还在不在再决定是否进入 Reconnecting 状态。状态机的实现不适合堆在回调里我会用独立的后台任务把发送命令、等待事件、超时处理的流程串起来。回调只负责把事件塞队列状态机负责消费队列两边解耦。出问题时也容易在日志里定位是命令没发出去还是事件没回来还是下载卡住了看状态转移记录一目了然。4.4 批量拍摄的内存管理每张照片都要闭环批量拍摄场景下内存问题会成倍放大。单张照片下载后图像对象、文件引用、目录项每一个都要走完创建-使用-释放的闭环。我见过一个同事的代码只漏了一次文件引用释放单次内存泄漏量很小但跑一晚上测 3000 张照片进程从 200MB 涨到 1.5GB界面开始卡顿最后直接被杀掉。解决思路是给整个下载链路套一个统一释放包装public void DownloadAndRelease(IntPtr dirItem, string savePath) { IntPtr fileRef IntPtr.Zero; try { EdsNativeMethods.EdsCreateFileRef(dirItem, 0, out fileRef); EdsNativeMethods.EdsDownload(fileRef, savePath, 0); EdsNativeMethods.EdsDownloadComplete(fileRef); } finally { if (fileRef ! IntPtr.Zero) { EdsNativeMethods.EdsRelease(fileRef); } } }这个模式的要点是不管中间哪一步抛了异常finally 里的 Release 都会执行。我还会在调试版本里加一个句柄计数器每次创建和释放各加加减减定时打印一旦发现存量持续上涨就立刻定位。这个习惯帮我提前发现过两次真实泄漏都是发生在不常走的异常分支里。5. EDSDK C# 开发避坑指南回调线程、内存泄漏与型号差异5.1 回调不触发先查委托引用和事件注册顺序现象相机能连能拍但程序里注册的回调一次都没进。原因多半是两种一是委托被 GC 回收前面已经强调过回调委托必须用字段持有二是事件注册晚于事件发生比如拍完照才注册对象事件。第三个隐蔽原因是事件掩码用错注册时把常量类型强转数值塞给 uint可能被截断注册的其实是另一个事件类别。解决注册前先打印要注册的事件掩码数值和 SDK 头文件里的定义逐字节核对。头文件就在 SDK 包里的 Inc 目录下常量都是明确定义的不要凭记忆写。5.2 句柄泄漏EdsRelease 少调一次就会缓慢爆炸现象程序跑几个小时后进程句柄数和内存稳步上涨相机端的响应越来越慢最终卡死。原因EDSDK 每次成功创建对象都返回一个非托管句柄你必须在对象不再使用时调用 EdsRelease。C# 的 GC 管不到这些非托管对象只能手动释放漏一次就多一份泄漏。解决用 try/finally 从句柄创建到使用结束整体包住finally 里统一 Release。我还会写一个调试计数器每次创建句柄加一释放减一隔一段时间打印当前存活句柄数。如果持续上涨直接排查哪条路径没有配 Release。最常见的就是回调里创建了文件引用但没释放或枚举列表后忘了释放列表。5.3 实时取景黑屏模式与口令不符现象StartLiveView 返回成功但取到的图像永远是黑图或者空图。原因EDSDK 的实时取景依赖相机处于静态图像拍摄模式。如果相机在视频模式或者回放模式实时取景命令虽然不报错但输出就是黑屏。另有一部分机身需要在开启实时取景前先锁定自动对焦设置。解决发 Evf 命令前先设置拍摄模式为手动或程序自动并回读确认。遇到特定机型还是黑屏就到 SDK 头文件里查针对该机型的专门命令给该机型的兼容逻辑单独写分支不要指望一套代码通吃所有机身。5.4 固件升级之后行为变化别把惯例当契约现象同一套代码今天拍得好好的明天相机固件升级后曝光参数写进去不生效了。原因固件升级会改变机身对参数范围和权限的判定尤其体现在新机光圈快门档位逻辑上。EDSDK 并不保证跨固件行为完全一致头文件里没有写死的东西都可能变。解决方案里强制加属性回读步骤设置完每一个关键参数后立即读回来比对。比对失败就报错不要静默继续。同时记录相机固件版本把参数表和固件版本钉在一起换固件等于换参数表。5.5 WiFi 连接下实时取景丢帧别拿 USB 的期望去要求 WiFi现象WiFi 连接相机后实时取景画面一卡一卡还偶尔断连拍摄下载时快时慢。原因EDSDK 在 WiFi 链路上走的是无线协议帧率和带宽都比 USB 低很多。尤其是在多设备干扰大的现场丢帧是正常现象而不是程序 Bug。把它当成 Bug 去调参往往调了半天也没结果。解决方案里做两种连接模式的参数分离。USB 模式可以跑满帧率WiFi 模式把取景帧率上限调低、超时时间放宽、下载改成队列串行。如果对实时性要求高干脆在硬件上规定用 USB不把 WiFi 作为可选项开放给操作员。6. 把示例工程改造成可交付方案日志、重试与参数持久化示例代码跑通只是第一步。一个能交给现场长期跑的系统至少要补上三件事结构化日志、自动重试、参数持久化。日志不能只在控制台输出。我会把每次命令的发送时间、命令码、错误码、耗时全部写入本地带时间戳的文件按天滚动。排查现场问题时一帧日志能省下半天。日志格式我倾向 TSV 而不是 JSON因为现场人员用文本编辑器就能看不需要额外工具。重试要分级。网络传输错误可以重试两三次但属性写入失败往往不是重试能解决的直接停机报警反而更专业。我的习惯是记录重试次数超过阈值就跳出不给操作员制造看起来还在跑的假象。重试逻辑放在独立后台任务里绝不要放在回调线程里否则死锁问题会把你拖进深渊。参数持久化这块把相机的全部关键属性包括 ISO、光圈、快门、白平衡、输出格式导出成 JSON 配置文件每台相机用配置序号关联一套参数。开机后按配置加载避免每次手工调整。这也是整个方案里最容易被低估的部分自动化系统跑得稳定靠的不是一个完美 API而是把每一份状态都掰开揉碎落进文件里让状态有据可查。最后说个教训。我在做第一版模拟项目 X 时把重试逻辑写在了回调线程里结果出现死锁界面卡死只能拔 USB。后来把重试和状态机挪到独立后台任务问题才真正消失。从那以后我改了一个习惯所有跨系统和跨线程的调用都只丢队列绝不在回调里干重活。这个习惯帮我避开了后续项目里至少两次同类问题。希望帮到你。本文还有配套的精品资源点击获取

佳能EDSDK C#开发实战：相机自动化控制从初始化到成片全流程

相关推荐

e2e不是缩写，而是工程协作的语境信号灯

CLRC663 Pin-to-Pin替代实战指南：硬件迁移的四大兼容维度与零PCB改动验证法

ESP32S3深度解析：面向边缘智能的双核AI开发平台

更多资讯

AnyPS5：低延迟本地串流方案，让任何设备秒变PS5延伸屏

中国土壤数据集从解压到栅格化的完整处理指南

CH592蓝牙MCU选型与实战：低功耗无线外设开发指南

Python数据预处理实战：从数据清洗到特征工程的全流程指南

Xilem 内置 Emoji 名称数据集（emoji_names）解析：CSV 格式、数据溯源与 emoji_picker 示例实战

WinForm中用ScottPlot绘制可拖拽贝塞尔曲线：坐标换算与实时刷新

今日更新

Susi AI API实战指南：susi_alexa_skill如何用Node.js调用chat.json获取智能回答

换新电脑了？KeyStats 恢复码数据找回完全指南，端到端加密统计一键重建

重建二叉树：由前序与中序遍历序列还原二叉树的原理与 Java 实现（YCBlogs 剑指 Offer 精讲）

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？