心形词云通过数学拟合或掩膜实现而非简单绘图：r的wordcloud2用r=1−sin(θ)极坐标采样，echarts需svg遮罩或canvas手绘，且须权衡可读性与形状精度。
心形词云不是靠“画个爱心再往里塞字”实现的，而是由词云渲染库在指定形状掩膜（mask）或路径约束下，把高频词按权重分布填充进心形轮廓——shape="cardioid" 是最直接有效的参数，但仅适用于支持该特性的库，比如 R 的 wordcloud2；而前端 HTML 环境中，ECharts + echarts-wordcloud 插件不原生支持心形，需手动构造 SVG 掩膜或改写布局算法。
用 ECharts + wordcloud 插件实现近似心形
ECharts 的词云扩展（echarts-wordcloud.min.js）本身只支持圆形、矩形等基础形状，没有 shape 参数。要逼近心形，只能靠“视觉欺骗”+ 后处理：
- 把容器
div#main宽高设为正方形（如600px × 600px），并添加 CSS 心形遮罩层（clip-path: path("M12 21.35...")），让溢出文字不可见 - 在初始化词云时，将
sizeRange设得较窄（如[12, 24]），避免小词挤在边缘失真 - 关闭自动旋转：
rotationRange: [0, 0]，否则心形轮廓会被斜向文字打散 - 必须启用
maskImage配合 Canvas 绘制的透明心形图（PNG），但注意跨域限制：本地双击打开会因file://协议导致canvas.toDataURL()报错
R 语言 wordcloud2 中 shape="cardioid" 的真实行为
wordcloud2 的 shape="cardioid" 并非渲染一个 SVG 心形再填字，而是用极坐标采样点，按心形函数 r = 1 − sin(θ) 动态计算每个词的落点，本质是数学拟合。它不依赖图像掩膜，因此导出的 HTML 可直接运行：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须传入两列数据框：
word列（字符串）和freq列（数值），缺一不可 -
size控制整体缩放，但心形密度受minSize/maxSize影响更大；设为0.5时，小词容易被裁掉 - 颜色若用
color="random-light"，部分浅色词在白底上可能看不清，建议加backgroundColor="#fff"显式声明背景 - 导出的 HTML 自带内联 JS，但若嵌入到已有页面，需确保
echarts.js和echarts-wordcloud.min.js已提前加载，否则报echarts.wordCloud is not a function
纯前端用 Canvas 手绘心形词云的硬核路径
如果拒绝外部库、坚持全 HTML/CSS/JS 实现，就得自己做三件事：生成心形点阵 → 计算词位置 → 绘制文本。这不是改几个 CSS 就能搞定的：
- 先用参数方程
x = 16 * Math.pow(Math.sin(t), 3)、y = 13 * Math.cos(t) - 5 * Math.cos(2*t) - 2 * Math.cos(3*t) - Math.cos(4*t)采样 200+ 个轮廓点，构建路径 - 对每个词，按权重随机选一个轮廓内点（可用射线法判断是否在心形内），再微调偏移避免重叠
- 用
ctx.fillText(word, x, y)绘制，但字体大小必须随权重缩放，且要手动处理换行和旋转——ctx.rotate()会影响后续所有绘制，必须用ctx.save()/ctx.restore()配对 - 性能瓶颈明显：50 个词以上就会卡顿，
requestAnimationFrame也救不了，因为每次重绘都要重新判断点是否在心形内
真正容易被忽略的是：心形词云的“形”永远服从于“词”的可读性。强行压缩所有词进完美心形，往往导致关键词变小、边缘词模糊。实际项目中，优先保证前 10 个高频词清晰可见，再用 clip-path 或 SVG 掩膜收边，比追求数学级心形更可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
