报表项目的报价单上，导出往往写在最后一行，或者干脆不写。它看起来只是一个按钮：数据都已经查出来了，再加个下载能有多难？真正的问题要到上线后才暴露——业务提出要把当前筛选结果导成表格，开发方才发现要动的不是按钮，而是整个权限链路。
导出权限之所以被低估，是因为它的成本不在界面，而在权限模型和数据侧。
“能看见”和“能拿走”是两套逻辑。查看权限可以靠菜单和角色粗略控制，导出的控制维度要细得多：哪些角色可以导、能导哪些字段、一次最多导多少行、涉及敏感信息的字段要不要单独屏蔽、导出动作要不要审批、要不要加水印、事后有没有日志可查。素材中把“按角色、按字段、按数据行控制导出，加水印和导出日志”单列为一项能力，常见的市场区间在一万到八万元。这个价格并不是凭空抬高的：每一层控制都要在查询链路上再校验一次，还要把结果写入审计。
第二重成本藏在性能上。页面展示通常分页，一次只返回几十行；导出是一次性拉全量。数据量到百万行级别，再叠加筛选和汇总，数据库压力完全不同，可能需要单独的统计表、索引甚至异步任务。这部分工作在页面开发阶段完全看不见，只有在业务点下“导出”的那一刻才会显形。
还有一层更隐蔽：导出会把口径问题固化。页面上算出偏差，用户扫一眼或许能察觉；一旦导成表格，文件就会流进邮件、会议材料和对外汇报里，错误被当成结论使用。所以导出权限和字段治理必须一起设计——比较稳妥的做法是让管理员维护一份可控的字段清单，业务只在清单内自由组合，而不是把字段无限开放。自助的边界划在哪里，直接决定了后期是“够用”还是“失控”。
这也是为什么导出常被放到二期，然后变成加价项。比较实际的做法是在需求阶段就把四件事写进范围：谁能导、导哪些字段、导多少行、要不要留痕。报价单上写清这几条，比事后争论“导出算不算在报表里”有效得多。
导出权限的设计目标，是让数据出口可解释，而不是把出口一封了之。
