先讲一个在很多企业里反复上演的场景。
运营部门每月要出一份经营月报，Excel 里的做法很成熟：一张工作表上摆好几块数据——订单明细一块、区域汇总一块、重点客户一块，每块数据各自带筛选。领导开会前想看某个大区的数据，点一下筛选按钮，几秒钟的事。
后来公司上了 Web 系统，月报搬进了浏览器。功能清单上写着"支持筛选"，验收也通过了。可真用起来大家发现：系统里筛选是按"列"来的，每个表头挂一个小漏斗图标，而页面上并排的几块数据互相牵扯；想筛"华东区"，得先弄清楚该点哪一列的漏斗；漏斗还是灰色的、不起眼的，不少用户根本没注意到它的存在。结果呢？系统有筛选，用户却在用肉眼找数据。
一个小图标的背后，是使用习惯的迁移成本
这类问题在 Excel 迁移到 Web 的过程中非常典型。表面上看，是"筛选按钮长得不一样"；往深了看，是三个真实的落差。
第一是位置落差。Web 表格把筛选固定在列头上，而业务报表的布局千变万化：仪表盘顶部要一个统一入口，宽表左侧要固定的操作栏，多块数据需要各自的触发点。入口一旦写死，页面设计就得迁就控件。
第二是认知落差。漏斗图标对年轻用户是常识，对财务、仓储岗位的老员工未必。他们认的是 Excel 里那个明明白白的筛选菜单——点开能看到全部选项、能排序、能清除。如果 Web 端的筛选交互让他们犹豫三秒以上，信任感就开始流失。
第三是范围落差。真实报表很少是"一格一张表"，常常是一张画布上多个数据块。用户的心智模型是"我要筛的是这批数据"，而不是"我要筛的是第 N 列"。工具若不能顺着这个心智走，用起来就处处别扭。
这些落差单看都不致命，叠在一起却足以让一个功能被闲置——而筛选恰恰是报表从"数据陈列"变成"分析工具"的分水岭。没人用筛选的报表，本质上还是一张静态大表。
SpreadJS 的思路：能力内置，入口开放
SpreadJS 是一款纯前端 JavaScript 电子表格控件，常用于在 Web 应用中重建类 Excel 的表格体验。在筛选这件事上，它的设计值得说道说道：筛选引擎是内置的——按条件隐藏行、筛选面板里的选项勾选、排序、清除，这一整套和 Excel 一脉相承的能力都在；但筛选的触发入口并不写死在列头。
开发者可以把默认漏斗收起来（通过 filterButtonVisible 一类的开关），改在自己指定的任何单元格里放置一个醒目的搜索或筛选按钮；点击时告诉筛选引擎"打开哪个列的筛选面板、在哪里弹出"。也就是说，同一个筛选面板，可以由页面上任何一个按钮唤起，指向任何一列。
回到开头那份经营月报，这就意味着：
- 页面顶部的"筛选"按钮可以同时服务下方多块结构相同的数据，一次配置，多处受益；
- 每块数据也能各配各的入口，互不干扰；
- 按钮上可以直接写"筛选""查找"字样，配品牌色，让不熟悉漏斗图标的用户一眼找到；
- 弹出的仍是用户熟悉的完整筛选面板——勾选项、排序、清除一样不少，老 Excel 用户不会有陌生感。
一句话概括：Excel 给用户的确定性保留了，Web 页面需要的布局自由度也补上了。
对不同角色，这件事值多少
对业务负责人：报表系统的采纳率往往卡在"用不起来"而非"没有功能"。筛选这种高频操作的顺手程度，直接影响一线人员是打开系统还是继续私下传 Excel。让既有能力真正被用上，比新增功能更能兑现系统投资。
对产品经理：这是典型的低本高收益项。不需要重构数据层，只是在交互层把入口做显性、做灵活，就能显著降低新用户的学习门槛。竞品演示时，"我们的筛选按钮可以放在任何想要的位置、长成业务需要的样子"也是一句听得懂、记得住的话。
对技术决策者：它反映了一个更本质的问题——表格控件的交互是否可定制。选型时值得把这类问题列入评估：默认 UI 能否替换？事件和方法是否开放？将来产品提出新的交互需求时，是被控件卡死，还是开发团队自己就能落地？
写在最后
数字化推进到今天，多数企业不缺报表系统，缺的是愿意每天打开它的一线用户。决定打开意愿的，常常不是宏大功能，而是筛选按钮放在哪、长什么样这类细节。把 Excel 里被验证过的习惯承接过来，再用 Web 的灵活性重新安排它们的位置——这正是 SpreadJS 这类前端表格控件的价值所在。如果你的产品也有一张"功能都有但没人爱用"的报表，不妨从筛选入口开始，重新审视一遍那些被默认样式定死的交互。
