SVG更适合静态/半动态拓扑图，支持缩放、语义化和CSS控制；Canvas适合高频重绘、超千级节点的实时场景；关键在按需选择而非盲目引入框架。
直接用原生 HTML5 就能做拓扑图，关键不是“能不能”，而是选 SVG 还是 canvas ——前者适合静态/半动态、需缩放和语义化（如可访问性、SEO、CSS 控制）的场景；后者适合高频重绘、节点数超千级、带物理模拟的实时拓扑。别一上来就引入 D3 或 HT，很多需求用纯 SVG + 原生 JS 就够了。
用 SVG 画节点和连线，坐标怎么设才不崩
硬写 cx="120" cy="85" 是最常见也最危险的做法：一旦数据结构变化或需要响应式，所有坐标全得重算。正确做法是统一用 viewBox 定义逻辑坐标系，再让容器控制实际尺寸：
-
viewBox="0 0 800 600"表示整个拓扑图在“800×600”的逻辑空间里布局，不管容器多宽都自动缩放适配 - 节点位置由数据驱动计算，比如树状拓扑按层级水平分布：
node.x = level * 200，node.y = depth * 120 - 所有
<circle>和<line>都用相对坐标，避免写死像素值；移动节点时只改cx/cy或x1/y1等属性，不要操作transform - 连线端点必须和节点坐标严格对应，否则拖拽时会“脱钩”——建议把节点坐标存在 JS 对象里，
<line>的x1直接绑定到nodeA.x，更新时同步赋值
SVG 连线加箭头，为什么 marker 不生效
这是 SVG 中最容易卡住的点：箭头本质是 <marker> 定义 + marker-end 引用，但漏掉任一环节都会失效。常见错误包括：
- 没把
<marker>放在<defs>里，或者<defs>没放在<svg>根元素内（不能放在<g>里） -
marker-end="url(#arrow)"中的#arrow必须和<marker id="arrow">完全一致，大小写、空格都不能错 -
<marker>缺少refX和refY，导致箭头尖不指向线段终点（推荐设为refX="10" refY="3"，配合markerWidth="10"） - 连线用了
<path>却忘了加fill="none"，箭头会被路径自身填充遮盖
拖拽节点时连线不同步，JS 怎么监听和更新
不要监听 mousemove 全局事件，容易冲突且性能差。标准做法是分三步绑定到具体节点上：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 给每个
<circle>加mousedown事件，记录当前节点引用和初始偏移，并阻止默认行为（e.preventDefault()） - 在
document上监听mousemove，计算新坐标后直接更新该节点的cx/cy，同时遍历所有以它为起点或终点的<line>，重设x1/y1或x2/y2 - 松开鼠标（
mouseup）时清理document上的监听器，避免内存泄漏 - 注意：不要在拖拽中频繁调用
getBoundingClientRect()，它触发重排；坐标应基于clientX/clientY减去容器偏移（container.getBoundingClientRect()只需算一次）
为什么用 canvas 画拓扑反而更难维护
Canvas 是“一次性绘制”，没有 DOM 节点概念，所有交互都要手动命中测试（hit-testing）。这意味着：
- 点击某个节点，你得自己写算法判断鼠标是否落在那个圆内（
(x-mouseX)² + (y-mouseY)² ≤ r²），不能靠addEventListener - 缩放和平移要自己管理变换矩阵，每次重绘前清空画布再重新 drawAll，性能随节点数下降明显
- 无法用 CSS 控制样式，颜色、线宽、字体都得写死在 JS 里；想加 hover 效果？得监听
mousemove并反复做 hit-test - 导出图片或打印时，Canvas 内容不会随 CSS 媒体查询变化，而 SVG 可以直接用
@media print控制显示
除非你明确需要每秒渲染 60 帧、节点数过万、或集成物理引擎，否则优先用 SVG。Canvas 的“高性能”只在特定条件下成立，多数拓扑图根本用不到那层优化。
