自研图表设计引擎 diagram-design：从数据模型到 Canvas 渲染的实战复盘-北京尧图网络

1. 为什么我放弃了现成绘图库决定从零写diagram-design过去一个多月我大部分时间都埋在一件看起来有点“重复造轮子”的事情里给系统自建一套名为 diagram-design 的图表设计引擎用来支撑架构图、流程图、拓扑图这类可视化编辑场景。起初团队的第一反应和我一样——去找现成的绘图库。市面上能画图的工具其实不少从纯展示型的 Mermaid、PlantUML到交互型的 AntV X6、LogicFlow、DrawIO 嵌入式方案甚至 Figma 这种重量级设计工具也提供了一部分嵌入能力。但真把需求逐条列出来之后问题就变得不那么简单了。1.1 需求清单我要的到底是什么先明确使用场景不是做一张静态的架构图扔进文档里而是要一个能嵌入业务系统、支持用户自由编辑的图表画布。核心操作包括节点拖拽、节点缩放、连线创建与编辑、多选框选、画布平移与缩放、撤销重做还要能自定义节点样式和类型。导出方面需要支持把图表导出成图片或 JSON 数据后续可能还要支持从 JSON 恢复成图表。如果只是“画一张图”上面任何现成库都能干。但真正让事情变得棘手的是下面几条节点类型需要完全由业务定制包括不同的形状、颜色、内部结构甚至内部还要嵌入图表小组件连线需要支持一种不太常见的路由方式——从端口出发的直角连线带避障能力交互手感要接近主流设计工具拖拽的平滑度、框选的精确度、缩放聚焦的位置都不能有明显偏差整体体积要可控不能为了画图引入一个几百 KB 的框架。1.2 与主流方案对比后的结论我把候选方案一个个过了一遍测试完的感受是这样的方案优势在我场景下的硬伤Mermaid / PlantUML上手快文本即图表只适合展示没法做交互编辑自定义节点非常受限AntV X6功能全社区活跃内置很多交互“全家桶”气质明显定制深了要读大量源码体积偏大LogicFlow流程编排场景很强可扩展性好侧重点在流程/编排通用图表编辑的框选、多层分组等能力需要大量二次开发DrawIO 嵌入开箱即用功能完整外部系统深度集成很痛苦UI 风格和操作习惯很难改成符合业务预期的样子从零自研完全受控按需实现需要投入研发成本但核心链路并不是无限复杂当时促使我下决心的是一次性能压测用同一份 2000 个节点的图数据在 X6 里拖动节点时明显感觉有延迟而我对这套图表的预期是至少能流畅支撑这种量级的浏览和基础编辑。与其在现成框架里反复优化和踩坑不如自己掌控渲染和交互链路。最终结论是自己写。核心算法和基础架构都自己设计把可控性牢牢握在手里。接下来的内容就是这次完整的实战复盘。2. 数据模型设计一份 JSON 如何描述一张完整图表表格设计往往是整个图表引擎里最容易被低估的部分。很多自研绘图工具做到一半发现改不动了根本原因就是数据模型没有设计好。diagram-design 在一开始就确定了数据驱动渲染的原则画面上的每一个元素都能在数据模型里找到唯一对应的描述。2.1 实体模型的四个基础对象我定义了四个基础对象Node节点、Edge连线、Port连接点、Group分组。为什么要单独定义 Port这是第一个关键决策。连线不是直接挂在节点上的而是挂在节点的 Port 上。这样设计的好处是一个节点可以提供多个连接位置比如输入在左、输出在右或者某个节点既有输入又有输出还有备用扩展口。当节点移动时Port 跟随节点移动挂在该 Port 上的连线自动跟着走。如果没有 Port 这层抽象连线的位置就只能锚定在节点中心或边缘根本无法表达“这一路从 A 节点的左侧入口进从右侧出口出”这种语义。Graph 模型核心字段interface GraphModel { nodes: NodeModel[]; edges: EdgeModel[]; groups: GroupModel[]; }NodeModel 的核心字段长这样interface NodeModel { id: string; type: string; // 节点类型渲染时对应注册的 Renderer x: number; // 左上角在画布坐标系中的 x y: number; // 左上角在画布坐标系中的 y width: number; height: number; style?: Recordstring, any; ports?: PortModel[]; data?: Recordstring, any; // 业务自定义数据渲染器自由使用 parentId?: string | null; // 所属分组 id zIndex: number; }这个设计里我刻意把嵌套层级拉平了子节点只用parentId指向父分组而不是用一个树形 JSON 嵌套存储。原因是拉平之后遍历、查找、过滤都变得非常简单不需要递归。对绝大多数节点操作——比如框选、命中检测、图层排序——我们总想做的是“枚举所有节点”而不是“递归找节点”。树形嵌套对序列化友好但对运行时操作太不友好了。2.2 坐标与尺寸该存什么精确坐标比偏移量更可靠节点坐标我统一存左上角坐标加宽高x、y、width、height而不是存中心点。原因很简单绝大部分几何运算都会涉及到包围盒BoundingBox的概念左上角宽高可以直接得到一个矩形后续做碰撞检测、框选、缩放都很直接。EdgeModel 我选择不存渲染时要走的全部路径点而是只存数据层面的首尾interface EdgeModel { id: string; source: { nodeId: string; portId?: string }; target: { nodeId: string; portId?: string }; router?: orthogonal | bezier | straight; style?: Recordstring, any; }中间的路径点不做持久化或者只做缓存不参与业务逻辑。为什么这样设计因为路径点本质上是布局路由阶段算出来的派生数据。上游节点的位置一变路径点就应该重新算。如果把它当作核心数据存下来就会出现“数据过期”——节点已经挪走了连线还停留在原地指向旧位置。这种做法把派生数据与核心数据分开是保证图表一致性的关键。2.3 命令式更新接口约束外部修改数据的路径数据模型确定之后下一个问题是外部业务代码怎么修改这张图最简单粗暴的做法是直接改对象属性比如node.x 100。但这样做的后果是没有办法统一感知变化、没有办法做撤销重做、没有办法批量合并更新。diagram-design 对外暴露的是一套命令式 API// 移动节点 moveNode(id, newX, newY, options?) // 调整尺寸 resizeNode(id, newWidth, newHeight) // 新增节点 addNode(nodeModel) // 删除节点及其关联连线 removeNode(id) // 新增连线 addEdge(source, target) // 批量更新多个节点的位置用于框选拖拽 moveNodes(ids, dx, dy)每个命令在内部会做三件事执行变更、更新画布、记录操作快照用于撤销重做。命令式接口把“改数据”和“改画面”绑定在了一起外部不用担心手动调用刷新导致的不一致。这个糖我强烈建议保留——哪怕前期觉得多写几层包装很麻烦后期所有的高级功能协同、时间线、批量操作几乎都需要依赖这样一层受控的变更入口。3. 渲染层选型Canvas 方案的绘制链路与性能优化渲染层的决策是整个引擎里我纠结最久的部分。最早我迷迷糊糊地先写了 SVG 版本后来数据量和交互复杂之后整体换成 Canvas中间也混过一段两者结合最终定型为纯 Canvas。这个摇摆过程本身就是一个很好的经验教训。3.1 SVG 与 Canvas 的两次弯路第一版我选了 SVG理由很充分DOM 结构天然支持事件绑定节点的增删改查非常直观不需要自己做命中检测。200 个节点以内的图SVG 用起来确实快开发效率高。但当我用 2000 个节点压测时问题全部暴露了出来拖动画布时整棵 DOM 树频繁触发重排和重绘帧率掉到 20fps 以下每次更新属性浏览器都要重新计算布局操作起来有明显的“粘滞感”。SVG 的优点是浏览器替你做了一切缺点恰恰也是浏览器替你做了一切——当节点数量大到一定程度它没有优化的余地了。于是我掉头尝试 Canvas 方案。Canvas 是即时模式绘图每次都要手动重绘整个画面没有“节点”这个概念只有像素。这意味着我要自己做一套模型到画面的映射还要自己实现命中检测。开发成本更高但一旦结构搭好性能的上限要比 SVG 高一个量级。目前主体渲染已经完全切换到 CanvasSVG 仅保留在某些导出场景中复用。3.2 从数据到画面的四个阶段Canvas 渲染管线的四个阶段依次是计算可视区域裁剪、绘制连线层、绘制节点层、绘制交互层。我按这个顺序固定了绘制管线目的是保证图层顺序一致避免连线盖住节点、交互框被节点遮住这类问题。function render() { clear(); // 阶段1视口裁剪只绘制可视区域内的元素 const viewport getViewport(); // 当前可视矩形世界坐标 const visibleNodes spatialIndex.search(viewport); // 阶段2连线层 renderEdges(visibleNodes); // 阶段3节点层 renderNodes(visibleNodes); // 阶段4交互层 renderSelection(); renderDragPreview(); }这里最关键的优化是视口裁剪。画布本身可能很大比如 10000×10000 的坐标空间但屏幕上能看到的可能只有 1000×800 的区域。所以每次渲染前先通过四叉树索引拿到当前可视区域内的节点只对这些节点做绘制。在 2000 个节点分布在 10000×10000 画布的场景里可视区域内的节点通常只有几十到几百个渲染压力很小。3.3 分层渲染与重绘调度把性能压到极限的实操方案Canvas 性能优化的第二板斧是分层画布。我实际用了三个叠加的canvas最底层画 Grid 网格中间层画连线和节点最顶层画交互状态框选矩形、拖拽预览、连线预览。分层的好处是交互层的内容变化不需要重绘整个节点层。拖拽过程中交互层每帧都在变但节点层只需要在节点真正移动时重绘。Grid 层甚至可以只在缩放或平移结束时重绘一次平移过程中通过 CSS transform 让浏览器直接位移画布不动 Canvas 内容这种特定场景下的作弊技巧对帧率提升非常明显。重绘调度用requestAnimationFrame统一合并let rafId null; function requestRender() { if (rafId) return; rafId requestAnimationFrame(() { render(); rafId null; }); }无论一帧里有多少次数据变更比如拖拽时每次 mousemove 都会改坐标实际渲染只会在浏览器下一帧执行一次。这样把渲染频率与屏幕刷新率对齐不会出现一帧多次重绘的浪费。还要特别说下高分屏适配。Canvas 在 Retina 屏上如果不处理 devicePixelRatio画出来会发虚。标准做法是把 Canvas 的实际像素尺寸放大 dpr 倍然后通过ctx.scale(dpr, dpr)让逻辑坐标不受影响canvas.width width * dpr; canvas.height height * dpr; canvas.style.width width px; canvas.style.height height px; ctx.scale(dpr, dpr);这个步骤看起来简单但很容易被忽略。早期版本忘了处理 dpr在 Mac 屏幕上文字和线条全部发虚排查半天才发现是这个问题。4. 布局引擎与自动排布层级布局和避障连线交互式图表编辑器的特点是人可以随便拖拖来拖去图就乱了。所以 diagram-design 里我加入了一个不算核心但影响体验很大的模块自动布局。用户可以在任意时刻“一键整理”整张图让节点按层次关系自动排列连线重新路由图表恢复清晰。4.1 有向无环图的层级分配布局的第一步是把用户画出来的图抽象成一个有向图并判断它是否适合分层布局。绝大多数架构图、流程图本质上是有向无环图DAG——数据从上游流向下游不允许形成循环依赖。层级分配采用“最长路径法”Longest Path Layering从所有源节点没有入边的节点出发节点的层级等于其所有前驱节点层级的最大值加一。逐层推进直到所有节点都有层级。这里的核心操作是用拓扑排序来保证处理顺序function assignLayers(nodes, edges) { const indegree new Map(); const adj new Map(); // 初始化入度与邻接表 nodes.forEach(n { indegree.set(n.id, 0); adj.set(n.id, []); }); edges.forEach(e { indegree.set(e.target.nodeId, indegree.get(e.target.nodeId) 1); adj.get(e.source.nodeId).push(e.target.nodeId); }); const queue nodes.filter(n indegree.get(n.id) 0); const layers new Map(); let depth 0; while (queue.length) { const size queue.length; for (let i 0; i size; i) { const id queue.shift(); layers.set(id, depth); for (const nextId of adj.get(id)) { indegree.set(nextId, indegree.get(nextId) - 1); if (indegree.get(nextId) 0) queue.push(nextId); } } depth; } return layers; }这种按“源节点为 0 层、逐层向外扩张”的方式保证每个节点都被分配到合理的纵向层级。同一层级的节点再按顺序横向排开。4.2 同层排序与减少连线交叉层级分好了每条连线的起点和终点都落在不同的层里。但一个具体问题马上浮现同一层的多个节点按什么顺序排如果纯按节点 id 排连线交叉会很严重。为此我实现了基于重心的排序法Barycenter Heuristic对同一层里的每个节点计算它的“重心”——即所有与它相连的上一层节点的平均位置按照重心值从小到大重新排列这一层节点反复迭代一般 3-5 次直到顺序稳定。这个算法不是全局最优但实践中效果已经非常接近主流库的水平而且实现简单、收敛快。如果你需要更严格的交叉最少化可以考虑 Integer Programming 或者基于递归划分的高级算法但对大多数实际场景重心排序已经足够。4.3 直角连线的避障路径规划连线的路径计算是布局引擎里最琐碎的部分。diagram-design 默认使用直角连线正交路由也就是连线只走水平或垂直方向。直角连线视觉干净、符合架构图的习惯但实现上需要额外处理避障。避障的核心思路是从源 Port 出发先走一段垂直方向到达通道区再沿水平方向前进到达目标 Port 的垂直线上时转垂直方向最终落到目标 Port 上。模型是一个“Z”字形的正交路径源端口 ---- | | | | | └---- 目标端口但连线路径可能会穿过其他节点矩形。最简单的检查方法是遍历所有节点包围盒判断线段和矩形是否相交。如果相交就在矩形周边选一个绕行点拆成两段线段矩形左侧被挡就在矩形左侧上方或下方绕矩形右侧被挡就往右偏移再绕多个连续碰撞就继续递归加绕行点最多递归 N 次后放弃。这个方案遇到复杂迷宫型遮挡会出次优解但配合自动布局后的规整图结构碰撞率极低。对 95% 的实际使用场景来说这个简化方案已经“够好”。我一开始就直接上复杂的 A* 寻路效果反而不稳定——路径绕来绕去很不好看最终放弃了。5. 交互设计拖拽、框选、连线这些操作的真实实现数据模型和渲染搞定后引擎只能“看”不能“用”。交互层才是从“一个绘图函数库”走向“设计工具”的分水岭。老话讲“图纸画得好不如交互跟手”用户对一个绘图工具的第一印象基本都来自这块。5.1 命中检测与四叉树索引Canvas 没有 DOM 层级关系每个鼠标事件都要靠我们自己判断“点到谁了”。最简单的做法是遍历所有节点逐个做矩形包含判断。但 2000 个节点时一次简单的 click 就要做 2000 次检测再加上 mousemove 每帧都在触发性能开销不可接受。我实现了一个四叉树索引把所有节点的包围盒按位置组织起来class QuadTree { constructor(rect, capacity 4) { this.rect rect; this.capacity capacity; this.nodes []; this.children null; } insert(node) { // 1. 如果当前节点未满且没有子节点直接放入 // 2. 如果已满拆分为四个子区域重新分配已有节点 // 3. 递归插入子节点 } search(rect) { // 返回与 rect 相交的所有节点 // 1. 当前节点的节点列表逐个判断 // 2. 与查询区域相交的子区域递归搜索 } }插入和查询复杂度都降到了 O(log n) 的量级。实测 2000 个节点的画布上 mousemove 命中检测的耗时从平均 2~3ms 降到了 0.05ms 以下完全感受不到延迟。5.2 画布拖拽与缩放的一体化坐标系交互中最大的概念陷阱就是坐标系。diagram-design 里有一套独立的坐标系变换这个变换是整个交互的基石必须一次想清楚。所有节点数据模型里的 x、y 都是“世界坐标”World Coordinates而浏览器鼠标事件给出的是“屏幕坐标”View Coordinates。两者通过画布的视口变换关联const transform { scale: number, // 缩放倍数如 1 表示原始大小 x: number, // 世界坐标原点在屏幕上的偏移 x y: number // 世界坐标原点在屏幕上的偏移 y }; // 屏幕坐标 - 世界坐标 function screenToWorld(sx, sy) { return { x: (sx - transform.x) / transform.scale, y: (sy - transform.y) / transform.scale }; } // 世界坐标 - 屏幕坐标 function worldToScreen(wx, wy) { return { x: wx * transform.scale transform.x, y: wy * transform.scale transform.y }; }平移画布的本质是改变transform.x/y缩放画布的本质是改变transform.scale同时调整transform.x/y使缩放中心对准鼠标位置。这里有一个非常重要的公式要让鼠标位置在缩放前后保持不动必须满足下面的关系// 鼠标在屏幕坐标 (mx, my) // 缩放前鼠标对应的世界坐标 wx (mx - transform.x) / transform.scale; wy (my - transform.y) / transform.scale; // 缩放后我们要让这个点的屏幕坐标还是 (mx, my) // mx wx * newScale newX // my wy * newScale newY // 解出 newX, newY newX mx - wx * newScale; newY my - wy * newScale; // 然后令 transform.x newX; transform.y newY; transform.scale newScale;所以缩放聚焦不是简单乘以一个 scale 就完事而是“变倍平移”的组合。很多小白自研工具做缩放聚焦时出现画面乱跳基本都是漏了后面这套平移补偿。5.3 操作状态机一次交互动作的生命周期管理画布上有很多种交互拖拽节点、框选、平移画布、创建连线、缩放。这些操作如果直接散落在事件回调里很快就会变成一团乱麻。我的做法是为每个交互设计一个状态机。以拖拽节点为例idle空闲→ 在节点上按下鼠标 →dragging拖拽中dragging→ 松开鼠标 →idledragging→ 按下 Esc 键 → 回滚到起始坐标 →idle具体到连线创建状态机是idle→ 在端口上按下 →connecting正在拉线→ 鼠标移到另一个端口上并松开 → 生成连线 →idle如果松在空白处则取消。所有异步交互都统一在这个模式里管理。每个状态都定义了进入时做什么、退出时做什么、以及状态间转换需要满足的条件。这样后期加新交互比如橡皮筋拖拽、多选套索时只需要新写一个状态机不会影响已有功能。6. 踩坑实录几个反复出现的坐标与性能问题这章节是实际开发中报错最多、最让人半夜惊醒的部分。每一个问题单独看都是小问题但组合起来它们决定了这个引擎到底是“玩具”还是“能上线的东西”。6.1 缩放之后拖拽节点漂移锚点换算错误现象是把画布缩放到 0.5 倍之后拖拽节点节点总是和鼠标错开一段距离。放大到 2 倍时这个偏移更明显感觉节点在“追”鼠标或“躲”鼠标。排查链路先在代码中定位拖拽的核心逻辑pointerdown时记录鼠标在屏幕坐标系的startMouse再记录节点的初始世界坐标startNodeX/Ypointermove时计算deltaScreenX currentMouseX - startMouseX然后直接加到startNodeX上。问题就出在最后一步deltaScreenX是屏幕坐标系的增量而startNodeX是世界坐标系的数值。缩放后两者的“一像素”长度完全不同。正确做法是先把屏幕增量转成世界增量deltaWorldX deltaScreenX / transform.scale再加到起始坐标上。这个 bug 的迷惑性在于缩放倍数为 1 时一切正常只有缩放后才暴露而很多人并不会每次测试都先缩放画布。我建议在写坐标换算工具函数时就统一用screenToWorld做一次转换不要暴露任何裸的增量。6.2 框选错位viewport 坐标与逻辑坐标混用框选功能实现后测试发现一个诡异现象鼠标框选的时候选择矩形的实际范围和鼠标画出的范围不一致缩放后偏差更大。节点多的区域尤其明显。排查后发现我在绘制选择矩形时用了世界坐标而鼠标绘制时用的是屏幕坐标两者直接混算。框选矩形本身应该用世界坐标存这样才能正确和节点的世界坐标做相交检测但鼠标的起点和终点要先通过screenToWorld换算成世界坐标再存。修正后选择矩形立刻精确落在鼠标画出的区域上。这个问题的普遍教训是在一次交互的内部逻辑里尽量不要混用两套坐标系要么统一转成世界坐标计算要么统一转成屏幕坐标计算。我的个人习惯是所有“持久化数据”和“几何运算”使用世界坐标只有“渲染直接相关”和“原始鼠标事件”才使用屏幕坐标。相交检测、矩形运算这类稍复杂逻辑一律先用变换函数清洗一遍数据。6.3 撤销重做内存泄漏与卡顿快照策略选择撤销重做最直观的实现是“快照”每次操作后把整个GraphModel深拷贝保存到一个栈里。一开始我用的是JSON.parse(JSON.stringify(graph))在 200 个节点的小图里毫无压力但到 2000 个节点时一次快照耗时 50-100ms连续拖拽节点时每帧都做快照直接卡死。排查和优化方案给“快速操作”如拖拽移动节点增加快照节流操作结束pointerup时记录一次快照而不是每次移动都记录对“高频操作”和“低频操作”分开处理拖拽是低频快照文本输入这种低频操作可以实时快照后续进一步改成“操作记录反操作函数”的方式比如记录 moveNode 的 from 和 to撤销时 moveNode(id, fromX, fromY)这才是一劳永逸的做法。实际操作层面我现在的实现是高频操作结束时入栈低频操作实时入栈栈容量限制为 100 步超出就丢弃最早的历史。6.4 Canvas 高分屏模糊与非整数缩放的文字渲染最后还有一个不高但非常影响观感的问题在 dpr2 的屏幕上Canvas 绘制出来的文字如果带有小数坐标会明显发虚。解决方法是所有矩形、文字的坐标在经过worldToScreen之后做一次Math.round或Math.floor取整让绘制像素对齐物理像素网格。function alignPixel(coord) { return Math.round(coord * dpr) / dpr; }这个方法的本质是把世界坐标转换到屏幕物理像素后再取整既保证了对齐又不会因为 dpr 的存在而出现缩放层面的偏差。7. 后续可以做的扩展从“够用”到“好用”到这里一个可以用的 diagram-design 基础版已经完整跑通了。但如果你想把场景从“能画”推向“真正好用”还有几个方向值得继续投入。第一个方向是协同编辑。当前数据模型和命令式 API 的设计天然适配协同场景。每条命令moveNode、addEdge、removeNode都可以被序列化成“操作日志”这些日志同步到远端后重放到其他客户端的画布上就能实现多人实时编辑。我在设计命令式 API 时考虑过这一点所以所有变更都走统一入口后续接 WebSocket 或 CRDT 都比较顺。第二个方向是更丰富的节点类型。目前节点是矩形为主配合注册机制可以自定义渲染任意内容比如内部嵌入迷你表格、仪表盘、状态灯等。结合分组功能可以把一张大型架构图的某个区域折叠成一个小封套节点大幅降低视觉复杂度。第三个方向是布局能力的增强。目前的层级布局对 DAG 图很好用但遇到树形图、力导向图比如网络拓扑需要补充对应布局算法。好消息是数据模型不挑布局任何算法只要输出每个节点的 x/y 就能和现有引擎对接布局模块和渲染模块完全解耦。回头看这次自研 diagram-design 的过程我最大的心得是绘图引擎的核心远比想象中扎实可控——坐标变换、数据模型、渲染调度、状态管理每一块都是经典问题都有成熟解法真正区分作品好坏的是交互手感和细节打磨。如果让我重新选一次我依然会走自研这条路但会更早地确定 Canvas 方案更坚决地推行命令式数据更新把坐标系换算从头到尾贯彻如一。希望这篇复盘能帮你少走一些弯路也欢迎交流你在这个领域遇到的坑和解决方案。

自研图表设计引擎 diagram-design：从数据模型到 Canvas 渲染的实战复盘

相关推荐

Repomix 开发者贡献指南：从环境搭建、项目结构到提交合并的全流程实战

本地大模型量化部署全栈指南：显存、延迟与精度的平衡术

2025年17款AI编程Agent全面盘点：从补全到自主执行

更多资讯

企业4A平台：统一身份管理与权限控制实战解析

DeepSeek-Reasonix 的 view_image 怎么让 AI 按路径读取本地图片

微信聊天记录导出完整指南:WeChatMsg 解密本地数据库并输出 HTML、Word、CSV

Kilo Code 接入 Cerebras：基于 CS-3 芯片的极速推理配置指南

Patches for indent on SerenityOS

AI商品图与短视频生成工具选型指南：跨境小团队数字产线闭环实战

今日更新

SpacetimeDB C++ 模块库实战：用 C++20 在数据库内构建 WebAssembly 模块

别踩雷！不是所有 AI 写作工具都靠谱，2026 高校认可工具精选

SSM+MySQL幼儿园管理系统源码解析：从部署到优化

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

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