ECharts 是实现漏斗图最稳妥方案，因其内置宽高计算、响应式缩放、点击下钻、移动端适配等能力，避免手写 SVG/CSS 导致的错位、归因失效、高 DPI 模糊及 IE 兼容问题；必须配置 sort: 'descending'、gap: 0、label.formatter 及语义化 data.name，并禁用外层横向滚动以保障体验。
直接用 ECharts 是最稳的选择，别自己手写 SVG 或 CSS 拼漏斗——宽高计算、响应式缩放、点击下钻、移动端适配全得重造轮子，且数据一变就容易错位或归因失效。
为什么不能用纯 HTML+CSS 写漏斗图
硬编码 width: 67.1% 看似简单，但实际项目中转化率会随日期、渠道、A/B 版本动态变化；一旦后端返回新步骤（比如在“下单”后加了“填写发票”），所有百分比都要重算，前端样式和 JS 逻辑全得手动改。更关键的是：border 或伪元素拼出的三角形在高 DPI 屏幕上边缘发虚，transform: scale() 在 IE11 中行为不一致，而漏斗图的核心诉求是“每个梯形宽度必须严格对应 UV 占比”。
ECharts 漏斗图必须配置的 4 个关键项
只设 series.type = 'funnel' 不够，漏斗图会默认按值升序排列、label 位置偏移、移动端点击失灵：
-
sort: 'descending'：确保最大值在顶部，否则漏斗上下颠倒 -
gap: 0：关闭层间间距，避免视觉断层（默认是 5，看着像阶梯不是漏斗） -
label.normal.formatter：必须显式返回{a} {c}或{b}: {c}，否则 tooltip 里 name 和 value 顺序错乱 -
data数组必须按业务顺序提供，不能依赖后端排序——ECharts 的sort只排数值，不保阶段语义顺序
点击下钻必须绑定 step.name，不是 index
运营要查“支付成功”这步的用户明细，代码写成 onClick: () => loadDetail(4) 是危险的。后端哪天加个“确认收货”步骤，序号全偏移，请求参数变成 ?step_index=4，结果拉回的是“下单”数据。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
正确做法是让每个 data 项带语义字段：
data: [
{value: 12400, name: '首页曝光'},
{value: 8320, name: '点击商品'},
{value: 5160, name: '加入购物车'},
{value: 3920, name: '下单成功'}
]然后在 chart.on('click', params => {...}) 里取 params.name 构造请求 URL：/api/funnel_detail?step_name=下单成功&date=20261025。
移动端漏斗容器要主动禁用横向滚动
手机屏窄，步骤一多，div#funnelChart 容器自动触发 overflow-x: auto，用户左右拖拽时实际只是内容溢出，不是平滑滑动漏斗层——体验割裂且误导。
解决方案分两层：
• 外层容器（如 <section class="dashboard"></section>）加 overflow-x: hidden
• 每个漏斗步骤内部（.funnel-step）设 overflow-x: auto 并启用 scroll-snap-align: start，让手指滑动时自动吸附到单步中心
