上次整理完第一套FineReport模拟题之后，后台陆续收到不少留言，有人问能不能再出一套进阶版，也有人直接问“FineReport下载以后到底怎么系统地自测”。趁着最近项目不忙，我把团队面试和日常答疑里最容易踩坑的点重新梳了一遍，凑成这套第二套模拟题。和第一套偏重基础操作不同，这套题把重心放在“易错点”和“工程落地”上——函数公式、参数联动、填报逻辑、性能优化、权限部署都有涉及，适合已经能用FineReport做出普通报表、但想往报表开发工程师方向走的人自查自测。
1. 为什么我把这21道题当成FineReport开发者的“体检报告”
很多人复习FineReport就是找一堆教程看，看完感觉全会，真到写题或者做项目立马露馅。模拟题本质上不是考试，而是一份体检报告：每道题对应一类真实开发中会遇到的能力点，做错不可怕，关键是错完之后能不能定位到自己的薄弱区域。
1.1 这套题覆盖了哪几个能力维度
我把报表开发工程师日常最常用的技能分成五个板块：基础认知、数据集与参数、函数公式、填报决策、性能权限部署。这五个板块基本对应了一个需求从“拿到需求”到“上线交付”的全流程。比如基础认知考察的是你对FineReport中普通报表和决策报表的理解，这决定了你一开始选什么模板类型；数据集与参数考察的是取数逻辑，直接影响数据能不能准确展示；函数公式考察的是复杂计算能力，是摆脱“拖字段”低阶操作的关键；填报和决策报表考察的是交互能力，判断你是否能做出“可用”的系统而不只是“能看”的报表；性能权限部署则是上线绕不开的坎。如果哪个板块错误率明显偏高，那么接下来补课的方向就很清楚了。
1.2 做题之前先记住这三条铁律
第一，FineReport里的公式和Excel的公式长得像，但底层逻辑完全不同，做题时别用Excel习惯硬套。第二，凡是遇到“数据没变”“样式不对”的题，先怀疑参数传递和父子格关系，这两个是最容易出问题的点。第三，简答题没有唯一标准答案，尤其是性能优化和权限控制，我给出的参考解法只是最常用的工程实践，你能写出更合理的方案同样算对。做题的时候建议给自己掐个时间，选择题判断题部分控制在30分钟内，函数计算和实操题控制在30分钟以上，整体算一次完整的模拟。
2. 基础认知题 5+3：模板类型、扩展方向、父子格、分页、参数，这些基本功不能含糊
基础题我故意没有出“FineReport是什么”这种概念题，而是挑了五个开发时会直接遇到的判断场景。这些题看着简单，但我在面试里问过很多人，正确率其实没有想象中高。
2.1 单选题（5道）
Q1. FineReport中，普通报表模板和决策报表模板的文件扩展名分别是？
A. .frm、.cpt B. .cpt、.frm C. .cpt、.xml D. .frm、.xml
Q2. 在单元格中绑定一个数据列后，默认的扩展方向是？
A. 纵向扩展 B. 横向扩展 C. 不扩展 D. 由父格决定
Q3. 关于“父子格”的说法，下列哪一项是错误的？
A. 父子格决定数据列之间的过滤关系 B. 单元格的扩展方向由父子格共同决定 C. 父子格仅影响前台显示效果，不影响数据结果 D. 分组报表中通过设置父子格实现分组汇总
Q4. 下列哪种方式最适合实现“每页固定显示N条记录”的需求？
A. 在单元格属性中设置“行后分页” B. 调整决策报表的组件布局 C. 在数据集SQL中使用过滤条件 D. 在参数面板中绑定普通文本控件
Q5. 关于模板参数与数据集参数的关系，下列说法正确的是？
A. 模板参数必须与数据集参数一一对应，否则报表无法运行 B. 数据集参数既可以被模板参数引用，也可以直接在数据集SQL中赋值 C. 模板参数只能在决策报表中使用，普通报表中无效 D. 数据集参数不需要在SQL语句中引用，系统会自动识别
2.2 判断题（3道）
Q6. 判断：FineReport设计器必须连接到FineReport服务器之后，才能编辑模板。
Q7. 判断：在决策报表的报表块中，单元格同样支持扩展和父子格设置。
Q8. 判断：开启“结果集缓存”后，每次刷新报表都会重新查询数据库，以保证获取最新数据。
3. 数据集与参数：3道案例题讲透“取数”这一关
数据集和参数是报表开发里出问题最多的环节。很多报表跑得慢、查不出来、按钮点了没反应，最后查下来都是参数和数据集之间没有衔接好。这一章我用三个场景题把最关键的知识点串起来。
3.1 案例题：内置数据集与外部数据集的选型
Q9. 报表参数面板上有一个“地区”下拉框，需要提供“华东、华南、华北”三个固定选项，且不依赖数据库查询。请你说出最简单的实现方案，并说明为什么。
这道题没有给选项，需要你自己写出方案。很多人一上来就说“我新建一个数据集，从表里select distinct地区”，但如果地区就三个固定值，完全没必要查询数据库。FineReport里可以用内置数据集，直接把三行数据写在模板里，下拉框的数据字典指向这个内置数据集；更轻量的做法甚至可以直接在控件数据字典里配置自定义值。
这里我需要强调一下选型原则：内置数据集的优点是数据随模板走、不依赖外部数据库、加载快，适合枚举值少且变化不频繁的场景；缺点是数据更新需要改模板，不适合动态数据。反过来，如果地区列表是随时可能变化的业务数据，那就老老实实用外部数据集，否则每次加一个地区都去改模板，维护成本太高。
3.2 实操题：带条件参数的SQL写法
Q10. 订单明细表中存在一个“地区”字段。现需要实现：当地区参数为空时，返回全部数据；当地区参数不为空时，按地区过滤数据。请写出数据集SQL。
这是报表开发中最经典的需求。推荐写法是用FineReport的模板参数替换语法，结合if和len函数判断参数是否为空：
SELECT * FROM 订单 WHERE 1=1 ${if(len(地区)==0, "", "AND 地区 = '" + 地区 + "'")}另一种常见写法是：
SELECT * FROM 订单 WHERE ('${地区}' = '' OR 地区 = '${地区}')两种写法都能实现，但第一种更推荐。原因是在参数为空时，第一种写法生成的SQL里完全没有“地区”过滤条件，数据库更容易走索引；第二种写法中有OR条件，某些数据库优化器可能无法有效利用索引，数据量大时会有明显性能差异。另外需要提醒，如果参数来自外部不可信渠道，直接拼进SQL会有注入风险，内部报表场景可接受，对外系统建议用参数化查询或对参数做严格校验。
3.3 排错题：点查询按钮后数据纹丝不动
Q11. 报表预览时，参数面板上的“地区”下拉框已经选择了值，点击“查询”按钮后，报表数据没有任何变化。请列出至少两种可能的原因。
这道题考的是排错思路。最常见的两个原因：第一，下拉框控件名和数据集SQL中引用的参数名不一致。比如控件叫“area”，SQL里写的是“${地区}”，那参数值根本没有传到数据集里，自然过滤不了。第二，数据集SQL里压根没有引用这个参数，或者SQL里虽然写了参数，但模板参数和数据集参数的绑定关系没配对。此外还有一种隐蔽情况：下拉框的“数据字典返回值”设置了，但实际值绑定没有正确关联，导致传给SQL的值是空字符串而不是选中的地区。最后还要记得检查查询按钮是否被自定义事件覆盖，FineReport里如果给按钮加了提交事件或JS，默认的查询刷新逻辑可能被替代，这类问题在前端代码排查时比较隐蔽，容易漏掉。
4. 函数与扩展运算符：从Excel思维到报表函数思维的切换
FineReport的函数体系继承了很多Excel风格，但真正拉开差距的是它的扩展运算机制。很多初学者在单元格里拖一个字段进去就完事了，遇到占比、同比、数组筛选这些计算就不知道怎么写。这一章的题目就是逼你把“面向单元格扩展”的思路建立起来。
4.1 占比计算里的扩展运算符
Q12. 订单明细中，A列为地区，B列为金额。现在需要在D列计算“当前行金额占全部订单总金额的百分比”，请写出D2单元格的公式。如果进一步要求“按地区分组计算占比”，公式又该怎么写？
这是非常典型的FineReport公式题，考察的是扩展运算符和过滤条件两个点。占全部订单总金额的百分比，公式是：
=B2 / SUM(B2[!0])这里的B2是当前行金额，SUM(B2[!0])表示对B2单元格所有扩展出来的值求和，[!0]是FineReport中“取全部扩展值”的写法。如果要按地区分组，需要加上过滤条件：
=B2 / SUM(B2[!0]{A2 = $A2})花括号里A2 = $A2的含义是：在B2的所有扩展值中，只保留A2扩展值与当前行A2相等的那些，然后求和。这里有个容易搞混的点：$符号在FineReport公式里并不是Excel里的“绝对引用”含义，它表示引用单元格当前扩展出来的值，写的时候要特别注意。
写完公式后记得把D列单元格的“形态”设置为百分比，小数位根据需求保留，否则单元格里显示的就是一串小数而不是百分比。这个细节经常被忽略，真正交付报表时会影响阅读体验。
4.2 同比增长率与相对引用
Q13. 现有C列为去年同期金额，需要在D列计算同比增长率，公式怎么写？如果C列为0时希望显示“-”而不是报错，又该如何处理？
同比增长率本身不复杂：
=(B2 - C2) / C2保持相对引用，扩展后每一行都会按当前行的B和C计算。这里真正想提醒的是除零问题。业务数据里去年同期金额为0完全不罕见，直接用上面的公式会出现除零错误。稳妥的写法是加个IF判断：
=IF(C2 = 0, "-", (B2 - C2) / C2)至于格式，可以设置单元格形态为百分比并保留两位小数，而不是在公式里手动乘100。很多从Excel迁移过来的人习惯公式里写“*100”，在FineReport里这样也行，但会破坏数据的原始含义，复用和后续计算都不方便，不如把显示形态交给单元格设置来管，公式保持纯粹的数值计算逻辑。
4.3 GREPARRAY与SQL函数的高阶用法
Q14. 数据集中有“金额”字段，需要统计单笔金额大于1000的订单数量。请写出一条使用GREPARRAY函数的公式实现该需求。
GREPARRAY是FineReport里处理数组的高阶函数，格式是GREPARRAY(数组, 条件)。结合LEN可以统计个数：
=LEN(GREPARRAY(B2[!0], item > 1000))这里的B2[!0]取出了金额列全部扩展值，item > 1000是遍历条件，GREPARRAY返回满足条件的新数组，LEN计算数组长度，也就是订单数量。如果不想用LEN，也可以用SUM配合IF来模拟，但GREPARRAY的写法更清晰，尤其是后续还需要对这组过滤后的数据做求和、求平均之类的操作时，返回数组一次搞定，比写一长串IF嵌套要高效得多。
Q15. 简述SQL函数在模板中的使用场景和潜在风险。
SQL函数的作用是在单元格里直接写查询语句取值，比如：
=SQL("FRDemo", "SELECT 金额 FROM 订单 WHERE 订单号 = '${订单号}'", 1, 1)适用场景是表格主数据集无法直接满足的零星补充数据，比如根据订单号去关联查询一个备注字段，而这个字段又不适合加进主数据集SQL里。这类需求偶尔用一下很顺手，但风险也很明确：SQL函数是单元格级别的，如果一个报表里有上百行数据，单元格公式中的SQL函数会被反复执行，每次执行都访问一次数据库，性能影响相当大。我见过一个报表因为在一个列里用了SQL函数，加载时间从3秒直接飙升到30秒，后来把这段逻辑合并到主数据集SQL里才解决。所以原则是：能合并到数据集SQL里的查询就别用SQL函数，SQL函数只适合低频、单点取值。
5. 填报与决策报表：从“报表能看”到“业务能用”的分水岭
普通报表看完数据就行了，但真正做到业务系统，填报和决策报表是绕不开的。填报让用户能回写数据，决策报表让驾驶舱和大屏成为可能。这一章的题偏实操，考察的是能不能理解FineReport的底层交互逻辑。
5.1 填报提交机制辨析
Q16. 判断题：在填报报表中，“内置SQL提交”和“智能提交”的核心区别是什么？请分别说明。
先说答案要点。内置SQL提交需要开发者手动配置插入、更新、删除三条SQL语句，提交时就按配置执行，灵活性最高，但配置量大，而且要自己处理主键冲突、字段变更等问题。智能提交只需要设置好主键和提交字段，帆软会根据当前行的状态自动判断应该执行插入还是更新，如果检测到删除操作也会一并处理。
实际项目里我更推荐优先使用智能提交，原因是可维护性好。内置SQL提交一旦表结构变了，SQL全部要改；智能提交只要字段映射里增删对应项就行。但智能提交也有前提，数据表必须存在明确的主键，而且主键不能是空的。如果遇到没有主键的临时表或视图，就只能回到内置SQL提交。另外，智能提交在数据量大时会有一定的性能开销，因为它需要逐行判断操作类型，这点在写需求方案时要提前评估。
5.2 决策报表自适应布局与联动
Q17. 决策报表制作驾驶舱大屏时，全局布局应该选择哪种模式？为什么？
答案是自适应布局。绝对布局在旧版本中用得比较多，它的特点是组件位置和大小都写死在画布上，设计时所见即所得，但投放到不同分辨率的屏幕上会出现两个问题：大屏上组件四周大量留白，小屏上组件溢出被截断或者出现滚动条。自适应布局则是设置一个基准设计尺寸，框架按比例缩放组件，让报表在不同分辨率的屏幕上都能保持整体结构不变形。做可视化大屏时，用自适应布局是后来的主流选择。有一点需要补充：自适应布局下，字体和边框的缩放逻辑也要提前测试，某些版本对字体缩放支持不完美，会导致大屏上文字明显偏小，这种问题往往到现场部署才会暴露，建议在设计阶段就拉一版接近真实分辨率的屏幕验证。
Q18. 简答题：点击决策报表中的柱状图某个柱子，让右侧报表块显示该柱子对应地区的数据，请至少说出两种实现方案。
第一种是超链联动。在图表“超链”里设置动态参数，把点击分类值传给目标报表块的模板参数，并让报表块的数据集引用这个参数。这种方式配置简单，适合地区、产品这类维度明确的一对一联动，开发效率高，稳定性也最好。第二种是用JavaScript事件。图表的交互事件中增加JS，获取点击分类值后调用contentPane.setParameterValue()和refresh()刷新目标报表块。JS方案更灵活，比如可以同时联动多个组件、做二次计算，但调试成本高，而且设计器和浏览器不同环境下行为可能不一致，需要多浏览器测试。我在实际项目中通常优先用超链联动，只有在需要额外处理数据格式或联动多个目标时才写JS。
6. 性能、权限与部署：上线前的三道必答题
报表做得再漂亮，线上卡成PPT也是白搭；权限漏了，数据安全就是一句空话。这一章的题来自真实上线场景，算是给“能开发”和“会交付”之间划了一条分界线。
6.1 报表打开慢的排查路径
Q19. 报表打开耗时超过10秒，请按优先级列出排查与优化步骤。
这道题没有标准答案，但好的答案应该有明确的优先级顺序。我把日常排查路径总结为以下几步：
第一步，查数据库层。把数据集SQL拿到数据库客户端执行，看单次查询时间和执行计划。如果SQL本身要跑5秒，后面调什么都是虚的，先把SQL优化好，该加索引加索引，该减少关联减少关联。第二步，查数据量。报表一次性查出了几十万行，但显示区域只需要几千行，可以考虑用分页或行式引擎缓解。第三步，查数据集重复。一个模板里多个数据集在查同一张基础表，能不能合并成一个数据集，减少重复查询。第四步，开缓存。在数据集高级设置中开启结果集缓存，让相同查询条件的结果直接复用；在服务器端开启模板缓存，减少模板解析的开销。第五步，检查单元格公式。尤其是前面提到的SQL函数和高成本数组运算，能移到SQL层的计算就别放页面层。第六步，才轮到调服务器参数，比如JVM内存、数据库连接池大小。很多人一遇到慢报表就去加服务器内存，其实大部分性能问题都出在SQL和报表设计上，服务器是最后该动的地方。
6.2 行权限控制的三种实现
Q20. 用户A只能看到华南区的数据，并且看不到金额列。请给出你的权限控制方案。
主要从两个层面考虑：行权限和列权限。
行权限最常见的实现是数据集SQL加过滤，在SQL里判断当前登录用户：
SELECT * FROM 订单 WHERE 地区 = '华南区'如果华南区不是写死的，而是跟用户绑定，可以用FineReport的内置参数或自定义权限参数实现，让数据集根据当前用户动态拼条件，这样不同用户登录看到的数据范围自动不同。更规范的做法是借助决策平台的数据权限设置，在服务器端统一做行权限控制，模板不写死SQL条件，而是由平台按用户角色下发过滤条件，优点是不用每张报表都改数据集。
列权限相对简单，决策平台可以控制某个用户角色是否能看到某个报表内特定列。但如果列权限很细，比如不是整列而是某个单元格隐藏，也可以直接在模板里根据值或权限参数控制单元格可见性。实际项目中我建议把行权限尽量做在SQL层，数据从源头就过滤掉，这样即使报表导出也不会泄露看不见的数据；列权限用平台功能控制，维护成本最低。
6.3 开发环境与生产环境的数据连接一致性
Q21. 开发环境使用数据库账号A，生产环境使用账号B。模板上线时，如何避免每张报表都改一次数据连接？
这道题看着是环境问题，实际上是项目规范问题。
最常用的解法是保持数据连接别名一致。开发环境和生产环境都叫FRDemo，设计器里模板只用FRDemo这个名字，具体连接的是哪台数据库、哪个账号，在对应工程的数据连接配置里维护。不同环境各有各的FRDemo配置，模板本身不用动。如果团队切换了数据库地址或账号，只需要在服务器端改一处配置，所有模板同时生效。
还有一类做法是把数据连接抽到服务器数据集或平台数据连接层，模板不再直接持有数据库连接配置，而是间接引用服务器端定义的数据源。这种方案适合多系统集成的复杂环境，但前提是FineReport工程的版本和部署架构支持，初期要做的配置工作也多。经验教训是：项目一启动就先定好数据连接命名规范，千万别在模板里写“本地测试连接”这种带环境色彩的连接名，否则上线时几十张报表逐一排查会非常痛苦。
7. 参考答案与逐题解析：我为什么这么出题
下面把上面所有题目的参考解析汇总一次。题目不容易，但每道题背后的工程逻辑比答案本身更重要。你现在可以对照前面自己选择的答案，逐题检查遗漏点。
7.1 基础认知题解析
Q1答案：B。.cpt是普通报表模板，.frm是决策报表模板。选错的人大多是记住了“frm是表单”但记反了对应关系。决策报表在FineReport里叫表单，它内部可以放报表块，报表块的底层仍然是普通报表引擎，所以看到“.frm”要联想到多组件、自由布局的驾驶舱场景。
Q2答案：A。数据列绑定到单元格后默认纵向扩展，这是FineReport最基础的行为。横向扩展需要手动切换到“横向扩展”，一般在月份、指标并列表头场景使用。实际开发中，纵向扩展和横向扩展混用时，父子格关系会变得复杂，所以我建议先搞清楚单一扩展方向，再研究交叉扩展。
Q3答案：C。父子格直接决定数据计算结果，而不只是显示效果。设置父子格本质是让数据列之间产生依赖关系，比如地区A2是左父格，金额B2是子格，则B2的数据在A2扩展范围内被过滤和分组。这个知识点考察频率很高，每次面试我都会问，因为报错排查时父子格是最容易引发连锁问题的环节。
Q4答案：A。“行后分页”可以在单元格属性中设置，让报表在指定行后强制分页，从而实现每页固定条数。设置数据集过滤只是限制数据量，和分页无关。决策报表组件布局也管不到普通报表的分页规则。需要补充的是，FineReport的分页预览和PDF导出都遵循这套分页逻辑，线下打印场景要提前设计好页边距。
Q5答案：B。模板参数是模板层面的变量，数据集参数是数据集查询里的变量，两者通过名称和绑定关系连接。模板参数可以传给数据集参数，也可以只用于单元格过滤、显示逻辑，所以A和C都不成立。D的错误在于数据集参数必须在SQL里显式引用，否则定义它不会产生任何过滤作用。
Q6答案：错误。FineReport设计器本地编辑模板并不强制要求连接服务器，预览时可以通过设计器内置的本地服务器直接运行。只有需要操作服务端资源（比如服务器数据集、权限配置）或者在服务器上预览时才必须连接远程工程。这个问题在搞前端集成的人里容易混淆。
Q7答案：正确。决策报表里的报表块本质上还是一个普通报表模板，扩展、过滤、父子格、公式等机制全部可用。很多人以为放到决策报表里就只能用“组件”思维，忽略报表块内部仍然是单元格模型，结果做复杂内容时反而绕远路。
Q8答案：错误。“结果集缓存”是把上一次查询的数据集结果缓存下来，下次查询条件相同时直接复用，减少数据库压力，并不是每次重新查询。要拿最新数据，应该关闭缓存或者明确使用实时数据配置。这里有个很容易被忽视的坑：报表数据很久没更新，不一定是你SQL写错了，可能只是缓存没失效。
7.2 数据集与参数题解析
Q9参考答案：使用内置数据集，在模板中直接添加三行数据“华东、华南、华北”，下拉框控件的数据字典指向该内置数据集；甚至可以直接在控件数据字典中配置自定义值，不需要建数据集。解析时重点强调“少量静态枚举值优先内置数据集”，这是很多开发者忽略的选型原则。内置数据集不依赖数据库连接，做原型或者边缘模块时能节省不少部署成本。
Q10参考答案见上文SQL写法。关键考点是参数为空时的兜底处理。这里再提醒一句：${}替换是文本级替换，构造复杂SQL时一定要检查引号和空值逻辑。如果地区参数有默认值，也可以在数据集参数里设置默认“全部”之类的选项，从源头减少空值判断。
Q11参考答案见上文。这道题考察的不是背答案，而是排错思路的完整性。我在面试时通常允许候选人先把自己最怀疑的原因说出来，再逐步补充。实际定位问题时，最快的办法是先在数据集预览里手动输入一个参数值，看数据集能否返回过滤后的数据，如果可以，问题就出在参数传递链路上；如果不可以，问题就在SQL本身。这个二分定位法几乎能解决大部分参数不生效的问题。
7.3 函数公式题解析
Q12参考答案：全文占比公式=B2/SUM(B2[!0])；分组占比公式=B2/SUM(B2[!0]{A2=$A2})。这两个公式是FineReport扩展运算的核心用法，建议把[!0]和{}的语义彻底吃透。我在项目里看到有人用隐藏辅助列求和再引用的方式实现分组占比，也能出结果，但模板复杂度明显上升，可维护性差，不如直接写扩展运算表达式。
Q13参考答案：=IF(C2=0,"-",(B2-C2)/C2)。注意这里返回“-”会改变单元格的数据类型字符串化，后续如果要对D列再做数值运算会有影响。更好的做法是保存数值结果，再用条件格式把异常值显示成“-”。不过业务需求简单时，第一个方案足够。核心考点是除零保护和显示形态分离。
Q14参考答案：=LEN(GREPARRAY(B2[!0], item > 1000))。GREPARRAY的item是遍历时的临时变量名，可以自己定义，但建议保持简短且统一。如果要对过滤后的金额求和，可以写作=SUM(GREPARRAY(B2[!0], item > 1000))，非常直观。这一题能把“数组思维”和“扩展思维”一起考到，所以我很喜欢出。
Q15参考答案：SQL函数适合低频单点取值；风险是单元格级循环执行会导致数据库压力骤增，建议合并到数据集SQL中。实际开发中，我给自己定的规矩是：单个模板中SQL函数出现次数不超过5次，否则就该重构数据集了。
7.4 填报与决策报表题解析
Q16参考答案：内置SQL提交手动配置增删改SQL，适合无主键表或特殊业务逻辑；智能提交按主键自动判断插入更新删除，适合绝大多数业务表，但必须有主键。填报提交类型选错会导致两种典型问题：一种是数据重复插入，因为没有按主键更新；另一种是更新覆盖了不该覆盖的行，因为没有配置好条件字段。所以提交前的“字段校验”和“主键确认”步骤一定不能省。
Q17参考答案：大屏首选自适应布局。这里补充一个细节：自适应布局不是简单的等比缩放，画布尺寸、组件拉伸策略、字体缩放策略都会影响最终效果。建议设计时按目标大屏最常见分辨率去定基准，然后在多个分辨率下用浏览器开发者工具模拟验证。绝对布局只适合固定投放设备的小型看板，不适合通用大屏。
Q18参考答案：超链联动和JS事件联动，见上文。补充一句：如果使用超链联动，目标报表块的参数名称必须和图表传递的参数名完全一致，大小写也建议保持一致，否则联动会失效。很多人做完联动没反应，八成是参数名字没对齐，而不是功能本身有问题。
7.5 性能权限部署题解析
Q19参考答案：按“SQL执行计划→数据量→缓存→报表设计→服务器资源”的顺序排查。这道题在项目里没有唯一答案，但最优解几乎都是从数据库层开始，因为报表慢的根因80%以上和数据查询有关。如果SQL本身没问题，再去看报表层的循环引用、重复查询和复杂公式。只有在这些层面全部排查完后，才值得去动服务器配置。
Q20参考答案：行权限写在SQL层，列权限用平台权限或单元格可见性控制。需要特别提醒的是“只控显示不控数据”是很多初级开发常犯的错误：前端隐藏了列，但导出Excel或者查询接口仍然能拿到敏感字段，这是数据安全事故。行权限必须从数据源头过滤，列权限也最好配合平台权限一起使用，不要只依赖前端隐藏。
Q21参考答案：统一数据连接别名，生产环境独立配置连接串。这看起来是配置问题，其实是项目管理问题。规范的别名管理和服务器端数据源配置，能让模板在不同环境下完全无感迁移。如果等项目上线前才统一改连接名，往往要改几十张模板，而且容易漏改，所以一开始就要立好规矩。
这套题我出得比第一套“狠”了一些，刻意把很多报表开发者在项目里容易含糊的细节摊开成题目。做的时候错几道都很正常，毕竟模拟题的价值就是让你发现自己还有哪里没到位。如果你做完发现函数公式部分错误率最高，那就说明平时在模板里拖字段拖习惯了，该试着把复杂计算写进单元格；如果是性能优化题没有头绪，说明你在“能跑就行”的阶段停留太久了，下一次做需求时不妨多问一句：这个报表数据量大起来之后还扛得住吗。把这些题吃透，比再刷十套教程都管用。
