上次整理完第一套FineReport模拟题之后后台陆续收到不少留言有人问能不能再出一套进阶版也有人直接问“FineReport下载以后到底怎么系统地自测”。趁着最近项目不忙我把团队面试和日常答疑里最容易踩坑的点重新梳了一遍凑成这套第二套模拟题。和第一套偏重基础操作不同这套题把重心放在“易错点”和“工程落地”上——函数公式、参数联动、填报逻辑、性能优化、权限部署都有涉及适合已经能用FineReport做出普通报表、但想往报表开发工程师方向走的人自查自测。1. 为什么我把这21道题当成FineReport开发者的“体检报告”很多人复习FineReport就是找一堆教程看看完感觉全会真到写题或者做项目立马露馅。模拟题本质上不是考试而是一份体检报告每道题对应一类真实开发中会遇到的能力点做错不可怕关键是错完之后能不能定位到自己的薄弱区域。1.1 这套题覆盖了哪几个能力维度我把报表开发工程师日常最常用的技能分成五个板块基础认知、数据集与参数、函数公式、填报决策、性能权限部署。这五个板块基本对应了一个需求从“拿到需求”到“上线交付”的全流程。比如基础认知考察的是你对FineReport中普通报表和决策报表的理解这决定了你一开始选什么模板类型数据集与参数考察的是取数逻辑直接影响数据能不能准确展示函数公式考察的是复杂计算能力是摆脱“拖字段”低阶操作的关键填报和决策报表考察的是交互能力判断你是否能做出“可用”的系统而不只是“能看”的报表性能权限部署则是上线绕不开的坎。如果哪个板块错误率明显偏高那么接下来补课的方向就很清楚了。1.2 做题之前先记住这三条铁律第一FineReport里的公式和Excel的公式长得像但底层逻辑完全不同做题时别用Excel习惯硬套。第二凡是遇到“数据没变”“样式不对”的题先怀疑参数传递和父子格关系这两个是最容易出问题的点。第三简答题没有唯一标准答案尤其是性能优化和权限控制我给出的参考解法只是最常用的工程实践你能写出更合理的方案同样算对。做题的时候建议给自己掐个时间选择题判断题部分控制在30分钟内函数计算和实操题控制在30分钟以上整体算一次完整的模拟。2. 基础认知题 53模板类型、扩展方向、父子格、分页、参数这些基本功不能含糊基础题我故意没有出“FineReport是什么”这种概念题而是挑了五个开发时会直接遇到的判断场景。这些题看着简单但我在面试里问过很多人正确率其实没有想象中高。2.1 单选题5道Q1. FineReport中普通报表模板和决策报表模板的文件扩展名分别是A. .frm、.cpt B. .cpt、.frm C. .cpt、.xml D. .frm、.xmlQ2. 在单元格中绑定一个数据列后默认的扩展方向是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 11 ${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(C20,-,(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参考答案统一数据连接别名生产环境独立配置连接串。这看起来是配置问题其实是项目管理问题。规范的别名管理和服务器端数据源配置能让模板在不同环境下完全无感迁移。如果等项目上线前才统一改连接名往往要改几十张模板而且容易漏改所以一开始就要立好规矩。这套题我出得比第一套“狠”了一些刻意把很多报表开发者在项目里容易含糊的细节摊开成题目。做的时候错几道都很正常毕竟模拟题的价值就是让你发现自己还有哪里没到位。如果你做完发现函数公式部分错误率最高那就说明平时在模板里拖字段拖习惯了该试着把复杂计算写进单元格如果是性能优化题没有头绪说明你在“能跑就行”的阶段停留太久了下一次做需求时不妨多问一句这个报表数据量大起来之后还扛得住吗。把这些题吃透比再刷十套教程都管用。