自助分析和固定报表最大的区别是：查询不是我们写的，是用户拖出来的。这一句话决定了这个模块的所有设计。
固定报表的 SQL 是开发写的、测过的、知道大概多快。自助分析里用户可以任意组合维度和指标，而他不知道也不需要知道数据量。第一版没有任何约束，上线后出的问题很集中。
第一是用户配出了跑不完的查询。用户把「用户 ID」「订单号」「时间（按分钟）」三个高基数维度拖到一起，结果集是几千万行的笛卡尔积。查询跑了很久没结果，用户以为卡了就刷新页面重新提交，于是同一个巨型查询在服务端跑了好几份，把这个租户的查询资源全占满，同租户其他人的报表全部变慢。
这里有两个问题叠加：一是没有事前约束，二是前端刷新页面并不会取消服务端的查询——用户看到的是「没反应」，服务端其实还在跑。
第二是指标被错误聚合。用户把「转化率」这个比率指标拖进来，系统按维度分组后对它求和，得出一个 300% 的转化率。用户拿着这个数字去质疑业务数据。比率类指标不能求和，必须先聚合分子分母再算比率——这件事用户不懂，界面必须拦住。
第三是结果集一次取全量导致浏览器崩溃。某个查询返回了几十万行，一次性取回并渲染，标签页直接崩了。
所以四个设计。
第一是提交前的代价预估：按各维度的基数估算结果行数（维度基数相乘是上界）和大致扫描量，超过阈值直接阻断。关键是报错要指出是哪个维度导致的——「你选的『用户 ID』维度有几百万个不同值，请改用『用户等级』或加上更严格的筛选条件」。只说「查询过大」用户不知道该改什么。
第二是长查询可取消，而且要真的取消服务端的执行。前端丢弃响应是不够的——服务端还在跑，资源还在占。所以取消要调一个真正的取消接口。这一条是解决「用户刷新导致同一查询跑多份」的关键。
第三是结果集分页加滚动懒加载，不一次取全量。用户看的通常是前几十行，全量取回是纯浪费而且会崩。
第四是配置层面的校验：维度组合是否合法（某些维度不能同时使用）、指标是否可聚合（比率类指标要标记为不可求和，聚合时走「先算分子分母再相除」的路径）。
代价预估选择「按维度基数估算」这种粗糙方法，而不是走数据库的执行计划。执行计划更准，但它需要真的把查询发给数据库解析，成本本身就不低，而且不同引擎的接口差异大。按维度基数相乘估行数上界虽然粗，但它足够识别出「量级明显不对」的配置——而我们要拦的正是这种，不是要精确预测耗时。取舍是会有误判（某些高基数维度加上强筛选条件之后实际结果很小，却被阻断了），缓解手段是把筛选条件的选择性也纳入估算，并提供「申请提升上限」的出口。判断依据是：预估的目的是拦住量级错误，不是精确预测，够用就好。
取消必须真的取消服务端执行，这一条不能省。只在前端丢弃响应实现最简单，而且用户体验上看起来一样（都是「不再显示结果」）。但它留下了一个隐形的资源占用——用户点了取消、又改了配置重新提交，服务端就同时跑着两个查询，而他自己完全不知道。这在多租户共享查询资源的场景下会放大成「一个用户拖慢整个租户」。教训是：前端的「取消」如果不传导到服务端，那它只是一个视觉上的取消。
指标的可聚合性做成元数据，而不是靠前端判断。前端可以按指标名称猜（带「率」字的不能求和），但这不可靠也不可维护。正确做法是让指标定义里带「聚合方式」这个属性（求和 / 求平均 / 先算分子分母再相除 / 去重计数），前端按元数据处理。代价是需要业务方把每个指标的聚合方式定义清楚，这在推进上有阻力（很多指标一开始没人说得清），但这个定义工作本身就是有价值的——它逼着业务澄清指标口径。
踩过的坑：用户配出几千万行的查询，刷新页面重提导致同一查询跑多份，拖慢整个租户。用户把三个高基数维度拖到一起，查询很久没结果，他以为卡了就刷新重新提交，反复几次之后服务端同时跑着好几份同样的巨型查询，同租户其他人的报表全部变慢，客户投诉「你们系统很慢」。修法是提交前代价预估阻断加真正的查询取消。教训是：把「构造查询」的能力开放给用户时，必须同时提供「代价可见」和「可中止」两个配套能力——只开放能力不给约束，用户会用出你没预料到的组合。
踩过的坑二：比率指标被求和，算出 300% 的转化率。用户把「转化率」拖进来按渠道分组，系统对各渠道的转化率求和，得出一个超过 100% 的数字。用户拿着这个截图来质疑我们的业务数据准确性，我们花了不少时间解释这是聚合方式的问题而不是数据错。修法是指标定义里带聚合方式，比率类走「先聚合分子分母再相除」。教训是：把分析能力开放给非技术用户时，「用错工具产生的错误结果」会被归因为「你们数据不准」——所以拦住错误用法比事后解释重要得多。
踩过的坑三：结果集一次取全量，几十万行直接把标签页搞崩。用户配了一个没有阻断但结果不小的查询，前端一次取回全部并渲染，标签页崩溃，用户以为是他电脑的问题。修法是分页加滚动懒加载，导出走异步任务。教训是：「页面展示」和「数据导出」是两个不同的需求，不能用同一条路径——展示只需要前几十行，导出才需要全量，混在一起两边都做不好。
踩过的坑四：保存的报表没记口径版本，指标定义变更后用户拿新旧数字对比。我们调整了「活跃用户」的定义，用户打开三个月前保存的报表，看到的数字和当时不一样，认为数据出错了。修法是配置里记录当时的口径版本，定义变更后打开时提示「此报表基于旧口径，当前口径已更新」。教训是：口径变更必须对历史报表可见——这和订单快照、审批规则快照是同一条原则的另一种形态：凡是会变的定义参与了结果，就要能追溯到当时用的是哪一版。
没做的部分：没做查询结果的缓存复用（相同配置在短时间内重复查询直接复用结果）。有收益但要处理缓存新鲜度与权限（不同人的行级权限不同，结果不能跨用户复用），复杂度不低。也没做查询的定时调度与订阅（每天早上把报表发到邮箱），需求存在但属于服务端能力。
被阻断的查询：报提交前阻断的次数与原因分布（哪个维度基数过高）。分布很有价值——如果某个维度反复导致阻断，说明它压根不该开放给自助分析，或者需要提供一个低基数的替代维度。
误阻断：要主动报——被阻断后用户申请提升上限并证明是合理查询的次数。承认误判并说明有例外出口，比声称预估很准可信。误阻断率过高会导致用户绕开自助分析回去提需求。
同一查询的重复提交：报「同一用户在短时间内重复提交相同配置」的次数，改造前后对比。改造前很高（用户以为卡了就刷新），改造后应该显著下降——这个数字直接证明「可取消」这个能力解决了真问题。
服务端资源占用：报取消操作真正释放服务端查询的比例。这个数字要接近全部，如果不是，说明取消没有正确传导。
指标误聚合：确定性验证——把比率类指标拖入并按维度分组，检查结果是「先聚合分子分母再相除」而不是求和。同时报相关客户质疑工单的消失。
预估准确性：报预估行数与实际行数的偏差分布。关键是要说明「预估长期偏乐观会让阻断失效」，所以要用实际数据回校阈值——这个持续校准的机制比一次性的准确率更重要。
不要报「查询性能提升 N%」。查询耗时主要由服务端与数据量决定，不是这个前端模块的成果。也不要报「零超时查询」——预估只能拦住量级错误，拦不住「很多个中等查询同时跑」，那一层在服务端配额。正确表述是「提交前阻断的次数与原因分布、误阻断的例外申请比例、重复提交次数的下降、取消真正释放资源的比例、指标聚合方式由元数据保证」。
先说清一件事，因为它决定了这个模块的全部难度：透视表和普通大表格不是一回事。
普通大表格是一维列表——行是记录、列是固定的字段，虚拟滚动只需要纵向。透视表是二维交叉：行和列都由用户拖出来的维度决定。用户把「地区、门店」拖到行，「年、季度、月」拖到列，于是：行头是两级的、列头是三级的、行头和列头都要跨行跨列合并（同一个地区下的多个门店，地区名要跨多行），而且列数也是不确定的（拖了三级时间维度可能有几十列），所以横向也要虚拟滚动。
第一版用现成的表格组件硬做，问题很快出现。
第一是表头错位。维度层级从两级变三级之后，表头的跨度计算错了，数据列和表头对不上——用户看到的是「一月」那一列下面显示的是二月的数据。这类错误极其危险，因为界面看起来完全正常，只是数字对错了位置。
第二是横向滚动时冻结区脱节。行头需要冻结（横向滚动时左边的地区门店要留在原地），而冻结区和主体是两个滚动容器，滚动位置不同步就会错行——左边显示「北京」这一行，右边的数据已经滚到了「上海」那一行。
第三是量级上不去。行列交叉之后单元格数量是行数乘列数，几百行乘几十列就是几万个单元格，用 DOM 渲染直接卡死。
所以四个设计。
第一是把表头结构预计算出来。数据到达后一次性算出：每一级表头有哪些节点、每个节点的跨度（跨几列或几行）、合并范围，形成一份结构描述。主体的单元格定位也用这同一份结构——表头和主体共用一份结构，就不可能错位。这一条是解决错位问题的根本。
第二是双向虚拟滚动：纵向按行、横向按列都只渲染可见范围。难点在合并单元格——一个跨五行的合并块，如果只有中间两行在可见范围内，它仍然必须被渲染，而且要正确偏移。所以裁剪逻辑不能简单地「取可见行的单元格」，要找出所有与可见范围有交集的合并块。
第三是三区滚动同步：冻结行头、冻结列头、主体是三个渲染区域，它们的滚动位置必须严格同步。做法是主体滚动时同步驱动另两区的偏移，而不是让三者各自监听滚动。
第四是列宽稳定：透视表的列宽如果按当前可见数据自适应，横向滚动时新列进入会导致已渲染列的宽度变化，整个表格抖动。所以列宽按内容一次性测算后固定，不随滚动变化。
表头与主体共用一份预计算结构，这是这个模块唯一真正重要的决策。另一种做法是表头和主体各自根据数据推算布局（看起来更解耦），但两套推算逻辑必然分叉，而分叉的表现就是错位——而错位是这个界面最危险的故障，因为它不报错，只是数字对错了位置，用户会拿错的数字做决策。共用一份结构的代价是结构预计算成为一个必须一次算对的关键路径，它的正确性要靠用例守住（不同维度层级组合、有无小计、空数据）。判断依据和其他几处一致：同一个东西不能有两份计算。
列宽一次性测算后固定，牺牲了「自适应内容」这个体验。自适应列宽在普通表格里是好体验，但在双向虚拟滚动的透视表里会造成抖动：横向滚动时新列进入视野，如果它的内容更宽导致列宽重算，已渲染的列位置全部偏移，用户正在看的单元格会跳走。所以固定列宽。取舍是某些列的内容会被截断，缓解手段是悬浮显示完整内容并支持手动调整列宽。依据是：在虚拟滚动场景里，布局稳定优先于内容自适应——这和聊天页「图片必须预存尺寸避免高度变化」是完全同一条判断。
用 DOM 渲染而不是 Canvas 画表格。Canvas 能画更多单元格、性能上限更高，但会丢掉文本选择、复制、无障碍支持、以及浏览器原生的查找功能，而报表场景里用户复制单元格内容到别处用是高频操作。所以选 DOM 加双向虚拟滚动，把量级做到「几万个单元格流畅」这个够用的水平。取舍依据是「用户的核心操作是什么」——报表用户要复制数据，地图看板用户不需要选中文本，所以两边的选择不同。
踩过的坑：维度层级增加后表头跨度算错，数据列和表头对不上。「一月」那一列下面显示的是二月的数据，而界面看起来完全正常，是客户核对数字时发现的。根因是表头的跨度计算和主体的列定位是两套逻辑，层级从两级变三级时只改对了一处。修法是共用一份预计算结构。教训是：错位类的 bug 比崩溃类的 bug 危险得多——崩溃会立刻被发现，错位会让用户默默用错数据，所以布局结构这类「一处算错就全错」的逻辑要收敛到单一来源。
踩过的坑二：冻结区与主体各自监听滚动，滚动时左右错行。两个容器各自绑滚动事件更新自己，时序上有差，快速滚动时能明显看到左边的行头和右边的数据错开一两行。修法是主体滚动时同步驱动另两区的偏移，只有一个滚动源。教训是：需要严格同步的多个视图，必须有一个明确的驱动方，让它们各自响应同一个事件不等于同步。
踩过的坑三：合并单元格在虚拟滚动下消失。裁剪逻辑是「取可见行范围内的单元格」，而一个跨五行的合并块，起始行滚出视野后它就不再被渲染，于是那一片区域变成空白。修法是按「与可见范围有交集」判断，并对部分可见的合并块做偏移渲染。教训是：虚拟滚动的裁剪单位必须和渲染单位一致——合并单元格的渲染单位是「合并块」而不是「行」，按行裁剪就会漏。
踩过的坑四：小计行参与了虚拟滚动裁剪，滚动时小计消失。用户滚到中间看不到小计，而小计恰恰是他最关心的数字，他的做法是滚回去看一眼再滚回来。修法是小计与合计行固定位置、不参与裁剪。教训是：虚拟滚动优化的对象应该是「大量同质的内容」，而语义特殊的少量行（小计、合计、表头）应该排除在外——一视同仁地优化会破坏它们的功能。
没做的部分：没做单元格级的条件格式（按值区间上色）。有需求但会让渲染逻辑复杂化，且在虚拟滚动下要保证颜色计算与滚动无关，当时优先做了正确性。也没做透视表的拖拽调整行列维度顺序（只能在配置区改），直接在表头上拖拽是更自然的交互，是个明确的体验缺口。
可流畅渲染的单元格量级：最该报的数字，而且单位要用「单元格数」而不是「行数」——透视表的负载是行数乘列数，只报行数会误导。要写明机型、浏览器、行列维度层级、是否有小计。
表头错位：确定性验证，而且要覆盖维度层级的多种组合（行两级列一级、行一级列三级、行列都三级、有无小计、空数据）。这是最该有常驻用例的地方，因为错位不报错、只会让用户默默用错数据。
冻结区同步：确定性验证——快速横向与纵向滚动，检查行头与主体始终对齐、列头与主体始终对齐。快速滚动是关键条件，慢滚可能测不出时序差。
合并单元格的可见性：确定性验证——把一个跨多行的合并块滚到「起始行在视野外、中间部分可见」的位置，检查它仍然正确渲染且偏移正确。这是踩坑后固化的用例。
列宽稳定：确定性验证——横向滚动全程，检查已渲染列的宽度不变、正在看的单元格不跳位。
小计可见性：确定性验证——纵向滚动到中间，检查小计与合计行仍然可见。
结构预计算耗时：要主动报，因为它是我们引入的一个新的关键路径。给出不同数据规模下的预计算耗时，并说明大结果集下是分片处理的。
不要报「支持百万行透视表」。透视表的可用性不只是渲染问题——百万行的透视表人是看不了的，它应该被更高层级的聚合替代。正确表述是「在什么条件下可流畅展示多少单元格、错位与合并裁剪与冻结同步各有常驻用例、列宽固定带来的布局稳定」，并说明超出量级时的正确做法是提升聚合粒度而不是继续优化渲染。
行级权限是 To B 报表里绕不过去的一件事：同一张报表，不同的人能看到的数据行不一样。部门经理只能看自己部门、区域负责人只能看自己管辖的区域、总部能看全部。
这件事本身不难（服务端按权限加过滤条件），但它衍生出三个很容易做错的问题。
第一是前端泄露了「被过滤数据的存在」。第一版为了体验友好，在列表底部显示了「另有 12 条数据你无权查看」。这句话本身就是信息泄露——它告诉了用户「存在 12 条他不该知道的记录」，在某些场景下这个计数本身就是敏感信息（比如从「另有 3 个部门」能推断出组织规模）。正确做法是前端压根不知道被过滤了多少，服务端过滤后的结果就是全部。
第二，也是最危险的：分享视图导致越权数据外泄。用户做好一张报表想分享给同事，第一版的实现是把结果快照存下来，生成一个链接。问题是快照里的数据是按分享者的权限查出来的——区域负责人把他的区域报表分享给一个只能看单个部门的同事，那个同事就看到了整个区域的数据。这是实打实的越权。
正确做法是分享只传递查询配置，不传递结果。查看者打开时按他自己的权限重新执行查询。这样同一个分享链接，不同人打开看到的数据范围不同——这正是想要的行为。
第三是「两人看同一报表数字不同」被当成数据错误。这是前两条的必然结果：既然按查看者权限重算，那么经理和总监打开同一个链接，总额就是不一样的。而用户不理解这一点，他们在会上对着不同的数字互相质疑，最后来问我们「你们的数据是不是错了」。
解法是在界面上显式展示当前的数据范围：「本报表基于你管辖的 3 个部门」。把权限差异从「隐形的困惑」变成「明确的说明」——这一条不改变任何数据逻辑，但它消掉了一整类工单。
另外两个必须一起处理的：
导出与定时订阅必须继承同一套权限判定。这是最容易漏的地方——页面上做了权限过滤，而导出接口走了另一条路径没过滤，或者定时订阅按报表创建者的权限跑然后发给所有订阅者。任何一个出口漏了，前面的过滤全部白做。
汇总值必须和明细在同一权限范围内计算。如果汇总走的是预聚合数据（没有行级权限）而明细走实时查询（有权限），用户会看到「总额 100 万，但下钻明细只有 60 万」——这不只是困惑，它还泄露了「有 40 万是你看不到的」这个信息。
分享只传配置不传结果，这是安全上的必然选择，但它有实实在在的体验代价。传结果快照的体验更好：打开即见、数字确定、不同人看到的完全一样，适合放进会议材料。传配置则意味着打开要重新查（慢）、不同人看到的不一样（会上对不上）。但传结果的方案在行级权限下是越权，这一条没有妥协空间。缓解体验代价的手段是界面显式展示数据范围，让「不一样」是可理解的而不是可疑的。如果业务确实需要「所有人看到同一份数字」，正确做法是走一个显式的「导出为固定报告」流程并由有全量权限的人操作、承担责任，而不是让分享链接默默泄露数据。
不显示「另有 N 条无权查看」，牺牲了体验友好度。显示这句话对用户是善意的（告诉他数据不全，避免他误以为这就是全部）。但它泄露了记录的存在与数量，而在权限设计里「不该看到的数据，连它的存在都不该被感知」是标准要求。取舍是用户可能误以为看到的是全量，缓解手段是用「本报表基于你管辖的 3 个部门」这种正向表述——它说明了范围，但不透露范围之外有多少。这个区别很微妙但很重要：说清自己的范围是安全的，说出范围之外的量就是泄露。
放弃查询结果缓存，代价是重复查询的成本。相同配置在短时间内重复查询本来可以复用结果，性能收益明显。但不同人的行级权限不同，结果不能跨用户复用；按用户维度缓存则命中率大幅下降、收益有限。所以我们放弃了结果缓存。这个取舍值得讲，因为它说明「权限模型会实质性地限制性能优化手段」——很多在无权限场景下理所当然的优化（结果缓存、预聚合、CDN 缓存）在行级权限下都不能直接用。
踩过的坑：分享视图用结果快照，造成越权数据外泄。区域负责人把他的区域报表分享给一个只能看单个部门的同事，那个同事看到了整个区域的数据，是在一次内部安全检查中被发现的。修法是分享只传查询配置，打开时按查看者权限重新执行。教训是：任何「把查询结果持久化并传播」的功能都要先问「这份结果是按谁的权限查的」——快照、缓存、导出文件、消息推送内容，都是同一个问题的不同形态。
踩过的坑二：前端显示「另有 12 条你无权查看」，被安全评估指为信息泄露。我们当时的理解是「这是友好提示」，而评估的意见是这个计数本身就是不该披露的信息。修法是服务端不返回被过滤计数，前端不显示相关提示。教训是：权限设计里「不该看到的数据，连它的存在都不该被感知」——这条比「不返回数据内容」严格一层，很容易被漏掉。
踩过的坑三：导出接口没走权限过滤。页面上的查询走了权限过滤，但导出是另一条链路，直接按查询配置生成文件，没有加权限条件，于是用户在页面上看到 60 条、导出的文件里有 100 条。这个漏洞是用户自己发现并主动报告的。修法是把权限判定收敛到查询执行的唯一入口，所有出口（页面、导出、订阅、开放 API）都经过它。教训是：权限过滤必须在数据出口的唯一收敛点实现，散落在各个接口里就一定会漏一个——而漏一个就等于全部白做。
踩过的坑四：汇总走预聚合、明细走实时查询，两者权限范围不一致。为了性能我们让汇总卡片读预聚合表（没有行级权限），结果用户看到「总额 100 万」但下钻明细只有 60 万，他先是困惑然后意识到「有 40 万是我看不到的」。修法是汇总与明细统一走带权限的查询路径，性能通过其他方式解决。教训是：为性能做的旁路会绕过权限，任何旁路都要单独审一遍权限——预聚合、缓存、只读副本、离线导出都属于这类。
没做的部分：没做字段级权限（同一行里某些列对某些人不可见）。客户提过（比如成本字段只有管理层能看），但它会让透视表的列结构因人而异，和「表头结构预计算」这个设计有冲突，当时按「整个报表可见或不可见」的粒度做。也没做权限变更的历史追溯（某人当时能看到哪些数据），审计场景下有价值但工作量在服务端。
越权路径：这一项只能用确定性用例覆盖，不能用比率。要为每一个数据出口各写一条用例：页面查询、导出、定时订阅、分享链接、开放 API——用低权限账号访问高权限用户创建的报表与分享链接，断言返回的数据在低权限范围内。报的是「覆盖了哪几个出口」，这个清单本身就是最好的证明。
安全评估结果：报客户方安全评估或内部安全检查发现的问题数与整改情况。诚实的表述是「发现过越权与信息泄露各一项，均已整改并补上回归用例」——承认发现过问题比声称一次通过可信，而「补上回归用例」说明是从机制上修的。
「数字对不上」类工单：报这类工单的数量变化，改造前后对比。这是「权限范围显式化」这个改动的直接业务收益，而且工单数是外部可核查的证据。
汇总与明细一致性：确定性验证——用受限权限账号查看报表，检查汇总值等于明细求和。这是踩坑后必须固化的用例。
订阅的权限跟随：确定性验证——修改某个订阅者的权限（或让他调岗），检查下一次订阅推送的数据范围随之变化，以及调岗后不再收到原部门报表。
放弃缓存的代价：要主动报——重复查询的比例与它带来的额外耗时，并说明为什么在行级权限下不能做结果缓存。主动交代这个取舍比等面试官问出来好。
不要报「零越权」或「权限准确率 100%」。安全类的绝对化断言最容易被问穿，而且只要将来出一次就被推翻。正确表述是「权限判定收敛在唯一入口、覆盖了哪几个数据出口的回归用例、安全评估发现的问题与整改、汇总明细一致性由用例保证」——说清机制和验证方式，比给一个绝对化数字可信。
没有匹配的内容，换个关键词试试。
项目拆解 · 自助报表与透视分析（Vue）· 共 3 个模块 · 数字均为示例，需替换成自己项目的真实数据