热力图需基于后端埋点数据聚合，前端仅负责Canvas手动渲染；坐标须归一化并快照容器尺寸，时间维度需四维预聚合，颜色映射应由服务端动态配置。
热力图本质是二维频次统计，不是纯前端能搞定的
直接用 JavaScript 在浏览器里画热力图，只能反映当前页面的点击/停留行为，无法体现真实用户活跃度（比如登录状态、跨页路径、时段分布）。真正有用的活跃度热力图必须基于后端采集的埋点数据，前端只负责渲染。常见错误是把 heatmap.js 或 echarts 的点击模拟当真实数据，结果热区全是测试人员自己点出来的。
- 真实场景中，
user_id、page_path、timestamp、event_type（如click/scroll/hover）必须由服务端统一接收并归一化存储 - 前端渲染时，坐标需对齐 DOM 实际布局（尤其响应式页面），不能直接用
clientX/clientY原始值，要转成相对容器的百分比或标准化像素坐标 - 时间维度不可省：同一位置在工作日 20:00 和凌晨 3:00 的权重应不同，需服务端预聚合为
hour_of_day × day_of_week × x × y四维矩阵
用 Canvas 手动绘制热力格子最可控
别迷信现成库。当你要支持千级 UV、百级页面、分钟级更新时，heatmap.js 的 maxOpacity 和 radius 参数调起来像玄学，且不支持离散坐标点加权。Canvas 手动绘制反而更稳——你清楚每一格怎么算、怎么 blend、怎么缩放。
- 先用服务端返回的聚合数据生成二维数组：
grid[y][x] = count，其中x和y是归一化后的整数坐标（例如 0–99） - 用
ctx.fillStyle = `rgba(255, 0, 0, ${Math.min(count / maxCount, 1)})`填充矩形，避免高斯模糊带来的性能抖动 - 鼠标 hover 时，通过
canvas.getBoundingClientRect()反查坐标，再查原始 grid 数组取对应count和时间切片，避免插值失真
响应式下坐标错位？关键在 container 尺寸快照
热力图一缩放就偏移，90% 是因为用了 offsetWidth 动态读取容器尺寸，但 DOM 渲染和 Canvas 绘制不同步。真实用户滚动/缩放时，getBoundingClientRect() 返回的宽高可能和你存的基准尺寸不一致。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 首次加载时立刻缓存容器的
width和height（用getComputedStyle(container).width+parseFloat），后续所有坐标转换都基于这个快照值 - 监听
resize事件时，不立即重绘，而是节流后触发「重新采样」：拉取新尺寸对应的历史聚合数据（服务端按设备宽度分桶，如width_bucket: "768-1024"），而非强行缩放旧 canvas - 禁止在 CSS 中给 canvas 设
width: 100%，必须用style.width和style.height显式设置，并同步调整canvas.width/canvas.height属性
颜色映射别硬编码，用服务端传的 palette
前端写死 ["#000", "#f00", "#ff0", "#fff"] 看着炫，但运营要按转化率分层（比如 >5% 为红色，1–5% 黄色，
立即学习“前端免费学习笔记（深入）”；
- 服务端返回类似：
{"breakpoints": [0, 1, 5, 20], "colors": ["#cce5ff", "#66b2ff", "#0073e6", "#003366"]} - 前端用
findIndex查当前格子 count 落在哪一段，再取对应 color，不依赖插值函数 - 如果某天运营想加个“夜间模式”深色主题，只需服务端换一套
colors，前端零改动
热力图最难的部分从来不是“怎么画”，而是“怎么定义活跃”。同一个按钮，被新用户点 10 次和被老用户点 10 次，业务意义完全不同；页面滚动深度 80% 和停留时长 10 秒，哪个更能说明内容吸引力？这些逻辑必须沉淀在服务端聚合规则里，前端只是忠实的显示器。
