HTML页面中脚本生成SVG：DOM操作与直接生成SVG代码的优缺点对比

你现在的需求是批量渲染带统一样式垂直线的SVG图表，已经尝试用内联SVG+marker+坐标变换的方式写了精简的SVG代码，但现在在纠结是直接操作DOM对象，还是生成SVG代码字符串插入页面，对吧？先看看你给出的示例SVG：

<svg style="background-color: #FFF;" width="300" height="180">
  <title>Bert Dobbelaere N9L25D7</title>
  <defs><marker id="dotB" markerWidth="4" markerHeight="4" refX="2" refY="2"><circle cx="2" cy="2" r="2" fill="black"></circle></marker></defs>
  <g stroke="black">
    <path stroke-width="0.05" d="M-.5 1m1-1v1m1-1v1m1-1v1m1-1v1m1-1v1m1-1v1m1-1v1m1-1v1m1-1v1"
     transform="matrix(0,20,333,0, 0,0)" /></g>
  <g marker-start="url(#dotB)" marker-mid="url(#dotB)" marker-end="url(#dotB)" stroke="black" fill="black" stroke-width="0.1">
    <path d="M0 1m0 0v6m.5-3v4m0-8v3m.5-1v3m1.7-5v7m.5-4v5m.5-6v2m0 1v1m1.7-5v2m0 4v1m0-4v1m.5-5v2m1.7 1v3m.5-5v3m0 1v2m1.7-1v2m0-5v2m0-5v1m.5 1v2m1.7 2v1m0-3v1m0-3v1m1.7 2v1m0-3v1m0-3v1"
     transform="scale(20)translate(0.65,0.5)" />
  </g>
</svg>

接下来咱们就针对你的场景，聊聊两种方案的优缺点：

一、方案A：直接操作DOM对象 #

优点 #

• 实时可控性强：每一个SVG元素（比如<path>、<g>）都是DOM节点，你可以随时通过JS修改它的属性（比如stroke-width、transform），或者监听它的事件（比如点击、hover），如果后续需要交互或者动态调整单条线条样式，会非常灵活。
• 无需排查字符串拼接错误：用DOM API（比如document.createElementNS创建SVG元素）生成节点，浏览器会直接处理合法的节点，不会出现SVG语法错误（比如标签未闭合、属性写错）。

缺点 #

• 代码冗余，性能开销大：就像你初步尝试的那样，要创建大量重复的线条，DOM操作需要逐个创建节点（比如每条线一个<path>或者<line>），哪怕用<g>分组，也得逐个添加子元素，脚本代码量会比生成SVG字符串大很多。尤其是你现在用path的d指令把多条线压缩成一个路径的情况，DOM操作没法直接复用这种“批量指令”的写法，只能逐个生成元素，初始化时的性能开销会更高。
• 内存占用高：大量的DOM节点会占用更多内存，如果图表数量多、线条数大，页面的内存压力会明显上升，可能导致卡顿。
• 坐标变换复用性差：你现在用transform把问题域坐标映射到屏幕坐标，DOM操作时需要给每个元素单独设置transform属性，或者手动计算每个线条的坐标，没法像SVG字符串那样一次性写好transform再批量渲染线条。

二、方案1：生成SVG代码字符串 #

优点 #

• 代码精简，性能高效：就像你示例里那样，用path的d指令把成百条垂直线压缩成一个路径字符串，配合transform统一做坐标映射，生成的SVG代码量极小，脚本只需要拼接字符串，然后插入页面（比如通过innerHTML或者svg.outerHTML），初始化速度非常快，适合批量生成大量图表的场景。
• 易读易维护：你用的是“问题域坐标”，SVG代码里的坐标都是业务逻辑里的数值，配合transform做缩放平移，人类读起来很直观，后续修改样式或者坐标规则时，直接调整字符串模板里的d指令、transform参数或者marker定义就行。
• 内存占用低：一个复杂的图表只需要几个DOM节点（<svg>、<defs>、几个<g>和<path>），不管里面有多少线条，都不会增加DOM节点数量，内存压力小很多。

缺点 #

• 动态修改麻烦：如果后续需要修改单条线条的样式（比如高亮某一条），或者给线条加交互事件，就需要解析SVG字符串找到对应的路径段，或者把路径拆分成多个DOM节点，这会变得很麻烦，不如直接操作DOM节点灵活。
• 字符串拼接易出错：手动拼接SVG字符串时，容易出现语法错误（比如引号未转义、标签未闭合、d指令写错），需要仔细检查，尤其是动态生成d指令里的坐标时，容易出现数值格式错误。
• 调试难度高：如果SVG渲染出问题，需要先看生成的字符串是否正确，再检查DOM结构，比直接操作DOM时用浏览器开发者工具直接查看节点属性要麻烦一点。

总结建议 #

如果你的场景是批量生成静态/半静态的图表，不需要太多动态交互，只是渲染大量统一样式的垂直线，那生成SVG代码字符串肯定是更好的选择——代码精简、性能高、内存占用低，完全符合你“保持SVG代码易处理、易读”的需求。

如果后续需要频繁修改线条样式、添加交互，比如点击线条高亮、动态调整线条位置，那可以考虑DOM操作，或者结合两种方案：用SVG字符串初始化图表，然后把需要交互的线条拆分成单独的DOM节点，兼顾初始化性能和交互灵活性。

备注：内容来源于stack exchange，提问作者greybeard