能，纯HTML+CSS可做静态信息图，但SVG是默认起点，D3.js仅在数据驱动且需交互时必要；导出需注意单位、渐变fallback和文件格式。
用纯 HTML + CSS 能做信息图表吗？能，但别硬刚
纯 HTML 标签（<div>、<ul>、<dl>）配合 CSS 的 flex、grid、transform 和伪元素，确实可以画出结构清晰的静态信息图——比如流程步骤、对比表格、环形占比示意。但一旦涉及精确比例刻度、曲线路径、动态数据绑定或响应式缩放，<div> 就开始抖。
- 适合场景：内部汇报页、轻量级博客配图、内容固定且无需交互的“一页纸摘要”
- 不适合场景：需要导出高清 PDF、适配不同屏幕宽高比、用户可点击展开某模块、数据来自 API 实时更新
- 常见翻车点：
width: 33.333%在 flex 容器里因 border/padding 计算错位；用em做字号缩放导致图标和文字比例崩坏
SVG 是信息图的默认起点，不是备选方案
所有现代浏览器原生支持 <svg>，它本质是 XML 描述的矢量图形，天生适配缩放、可被 CSS 控制样式、能用 JS 动态修改 attr 或 style。你画一个圆，改它的 cx、cy、r，就是改位置和大小；填个 fill，就是换色——没有重排、不触发回流。
- 用
<g>分组逻辑模块（比如“用户增长”区块），方便整体平移或添加class - 文字用
<text>而非包裹<div>，避免字体渲染错位和换行不可控 - 图标优先用
<path>或<symbol> + <use>复用，别塞 base64 图片 - 注意：直接内联 SVG 时，
<style>标签在<svg>内部是合法的，但外部 CSS 选择器要写成svg .label，不能漏掉svg前缀
什么时候必须上 D3.js？看这三点
D3 不是“画图库”，是“数据驱动文档”的操作框架。它本身不提供图表组件，而是帮你把数组映射成 DOM 元素，并绑定数据。是否该用，只取决于三个条件是否同时成立：
- 你的数据源是 JavaScript 数组或对象（比如
[{name: 'A', value: 24}, {name: 'B', value: 56}]） - 你需要根据数值自动计算坐标、半径、颜色亮度等（而不是手写
cx="120"） - 后续可能增加交互：悬停显示详情、点击筛选、拖拽重排顺序
典型错误是拿 D3 渲染一个静态饼图——结果写了 80 行代码，不如手写 4 个 <path> 加 4 行 CSS。D3 的价值在「数据变，视图自动同步」，不是「画得更像」。
立即学习“前端免费学习笔记（深入）”；
导出和兼容性：别等上线才发现打不开
信息图最终常要嵌入 PPT、转 PDF 或发给没技术背景的同事看。这时最容易忽略的是：
- 使用
rem或vh/vw单位时，导出工具（如 wkhtmltopdf）可能不识别，强制改用px或内联 style - 渐变（
<linearGradient>）在旧版 Safari 或某些邮件客户端里会降级为纯色，加fill="#333"作 fallback - 如果用了
filter: drop-shadow()，部分 PDF 导出器会丢阴影，改用<feDropShadow>写在 SVG 里才可靠 - 对外交付时，优先提供
.svg文件（不是截图），并附带一行说明：“双击可查看源码，用浏览器打开即见矢量效果”
真正难的不是画出来，是让这张图在三个月后、换了个设备、进了另一个系统，依然能准确传达那几个数字之间的关系。细节都在单位、命名和 fallback 上，不在炫技的动画里。
