企业官网建设流程全解析

简介：这份文档面向使用Smartbi进行电子表格报表开发的初学者与业务分析人员，系统梳理了从模板引用到预览发布的完整设置流程，可帮助读者快速掌握报表样式设计与参数控制的关键操作。包内共1个docx文件，压缩包约1.05MB，以图文步骤与代码片段相结合的方式组织内容，便于边看边练。文档覆盖引用模板、页面设置、隔行不同颜色、列宽自适应、参数设置、参数排版与预览发布七个环节，其中列宽自适应与参数校验部分给出了可直接复用的宏代码，例如限制结束日期不早于开始日期且跨度不超过90天的实现思路，参数排版也附有每行数量分配的经验说明。目前已有1302人学习下载，适合需要按步骤搭建规范报表、减少重复调试的读者参考借鉴。

1. 一份能直接抄的 Smartbi 报表设置清单：从模板引用到参数校验的七个动作

做报表的人大概都遇到过这种场面：需求方甩过来一句“照着这个 Excel 做一版”，你打开文件一看，冻结窗格、隔行底色、列宽、参数联动全都有，但真到 Smartbi 里复现，样式对不上、列宽挤成一团、日期参数还能选出“结束早于开始”的离谱组合。这份 Smartbi 报表设置文档解决的正是这类落地问题——它不讲产品架构，只把引用模板、页面设置、隔行变色、列宽自适应、参数校验、参数排版、预览发布这七个动作拆成可照做的步骤，其中列宽自适应和日期区间校验还给了可直接粘贴的宏代码。适合刚接手 Smartbi 电子表格报表的开发者，也适合已经会用但总在样式和参数上返工的老手，下面按我实际拆这套文档的顺序讲。

2. 模板引用与页面设置：先把骨架搭对再谈美化

2.1 引用模板这一步决定了后面所有样式的基准

Smartbi 的电子表格报表本质上是“Excel 设计器 + 服务端渲染”的组合，所以第一步不是急着画表格，而是把模板引进来。文档里的做法是在 Excel 中打开 Smartbi 页签，登录后点“模板”再“打开模板”，在模板基础上改样式。这个顺序有讲究：模板里通常已经预置了报表的冻结行、打印区域、字体族和单元格命名规范，你直接在模板上改，等于继承了一套已经调好的基准；反过来新建空白表再手工对齐，后面隔行变色和列宽自适应很容易和模板的默认行为打架。

常见做法是先在模板里确认三件事：冻结窗格的位置、表头占用的行数、参数区预留的行列。文档里特别提到“第一行是空白行，所以上面报表冻结的是 1-5 行”，这句话看着不起眼，但它解释了为什么冻结范围要从第 1 行算到第 5 行——空白行也是行，冻结区域是按物理行号算的，不是按你眼睛看到的表头算的。很多人冻结设成 1-4 行，预览时表头被切掉半截，就是漏算了这行空白。

操作上建议按这个顺序走，别跳步：

1. 登录后在 Smartbi 页签点“模板”→“打开模板”，选中目标模板；
2. 在模板上改表头文字、调整数据区占位，不动冻结行和命名区域；
3. 确认第一行是否为空白行，据此决定冻结行号；
4. 保存前先在 Excel 里本地预览一次，看冻结和打印区域是否正常。

提示：模板引用后不要随手删空白行，删了冻结范围会整体上移，后面参数区排版也跟着错位。

2.2 页面设置里冻结行号和空白行的关系

页面设置这块文档写得简，但它是后面所有视觉问题的源头。冻结窗格的作用是预览和发布后滚动时表头不跑，而 Smartbi 电子表格的冻结是按 Excel 的行号来的，所以“第一行是空白行”这个事实必须写进你的设置里。我一般会先在 Excel 里把行号显示出来，数清楚表头实际占哪几行，再决定冻结到第几行，而不是凭感觉填个 5。

除了冻结，页面设置还要顺手确认打印区域和缩放比例。报表最终多半要导出或打印，缩放比例设成“调整为 1 页宽”能避免列多时被切成两页，这个和后面的列宽自适应是配套的：列宽自适应让内容不挤，缩放让整表能落在一页里，两者一起调才稳。如果只做自适应不管缩放，列宽是舒服了，打印出来还是断页。

这里有个容易忽略的点：页面设置改完要重新预览一次，因为冻结行号、打印区域、缩放三者会互相影响。改冻结行号后打印区域可能跟着变，改缩放后冻结的视觉位置也可能偏移。文档把页面设置放在第二步而不是最后，就是让你在样式动手之前把骨架定死，后面隔行变色和列宽自适应才有稳定的基准可依。

3. 隔行变色与列宽自适应：样式脚本怎么写才不翻车

3.1 隔行不同颜色的两种实现路径与选择理由

隔行变色文档只给了结论没给细节，但这一步在实际项目里返工率不低。常见做法有两条路：一是用 Excel 的条件格式（Conditional Formatting）配公式，二是用 Smartbi 宏在渲染时给行加样式。两条路各有边界，选错了后面维护很痛苦。

条件格式的优点是纯配置、不写代码，公式类似=MOD(ROW(),2)=0就能让偶数行变色，改颜色直接改格式规则，非开发人员也能维护。缺点是它依赖 Excel 的行号，一旦报表有合并单元格或者数据区起始行不固定，公式的ROW()基准就会漂，颜色跟着错位。宏方式的优点是可以在渲染回调里按数据行索引判断，合并单元格和动态数据区都不影响，缺点是得写代码、得懂spreadsheetReport对象，改样式要动脚本。

我的选择习惯是：数据区行数固定、没有复杂合并的报表走条件格式，省事；数据区行数动态、有分组或合并的走宏。文档把隔行变色放在列宽自适应前面讲，顺序是对的——先定颜色再调列宽，因为列宽变化不影响行底色，反过来先调列宽再改条件格式规则，容易把格式刷丢。

如果走条件格式，操作步骤是：选中数据区→开始→条件格式→新建规则→使用公式→输入=MOD(ROW(),2)=0→设填充色→确定。注意选区要从数据首行开始选，不要连表头一起选，否则表头也会被染色。如果走宏，就在渲染回调里遍历行、按索引设backColor，逻辑和下面列宽自适应的宏是同一套对象模型。

3.2 列宽自适应宏：全局与单列的取舍

列宽自适应是这份文档里最实用的部分，因为它给了一段通用宏，能解决“列多时手动拖列宽拖到怀疑人生”的问题。先看代码：

function main(spreadsheetReport) { var sheet = spreadsheetReport.workbook.worksheets.get(0); if (sheet === "" || sheet === null) { return; } var counts = sheet.cells.maxDisplayRange.columnCount; // 获取电子表格列数 sheet.autoFitColumns(0, counts); // 从 0 开始，到 counts 列结束 // sheet.autoFitColumn(3); // 只对某列进行自适应，第一列为 0 }

逻辑说明：main是 Smartbi 宏的入口函数，渲染时由框架调用并传入spreadsheetReport。第一行取第一个工作表，第二行做空值保护——get(0)在极端情况下可能拿不到表，不判空后面直接报错。第三行用maxDisplayRange.columnCount拿当前显示范围的最大列数，注意是“显示范围”不是“整张表”，所以隐藏列不会被算进去，这正好符合报表场景。第四行autoFitColumns(0, counts)从第 0 列到第 counts 列批量自适应。

参数说明：autoFitColumns(start, end)的区间是左闭右开的常见约定，传(0, counts)覆盖全部列；如果你只想调某一列，用注释里那行autoFitColumn(3)，索引从 0 开始，第 3 列其实是第四列，这个偏移是新手最容易踩的。调试阶段建议先单列调，确认索引对得上再放开全局，因为全局自适应在列特别多时会让某些窄内容列被撑得过宽，反而难看。

注意：autoFitColumns是按内容算宽度的，如果某列里有超长文本或换行符，自适应结果可能超出预期，必要时对该列单独设固定宽度而不是走自适应。

3.3 全局自适应和单列调试的配合节奏

实际调报表时我不会一上来就全局自适应，而是先跑单列。原因很实际：全局自适应一次改所有列，哪列宽了哪列窄了你根本分不清是内容问题还是索引问题。单列调的时候把autoFitColumn(3)那行放开、把全局那行注释掉，改一个索引看一列效果，确认无误再切回全局。

还有一个节奏问题：列宽自适应应该放在隔行变色之后、参数排版之前。因为参数区排版会改变参数控件的行列分布，如果你先自适应再排版，参数区一挪列宽又得重算。文档把列宽自适应放在第四步、参数排版放在第六步，中间隔着参数校验，这个顺序是合理的——样式先定，逻辑后加，最后排版收口。

调试时如果发现某列怎么调都不对，先看这列是不是有合并单元格。autoFitColumns对合并单元格的处理是按合并区域整体算的，单列自适应可能只作用于合并区左上角那一格，视觉上就像没生效。遇到这种情况，要么拆合并，要么对这列改用固定宽度。

4. 参数校验宏：日期区间约束怎么写才不打断刷新

4.1 重写 doRefresh 的思路与代码逐行拆解

参数校验是这份文档里技术含量最高的一段，它要解决的问题很具体：报表有{开始日期}和{结束日期}两个参数，需求要求结束不早于开始、且跨度不超过 90 天。难点在于校验时机——你不能在参数一变就弹窗，那样用户还没选完就被打断；也不能等查询跑完再校验，那样白跑一次。文档的做法是重写doRefresh，在刷新动作真正执行前拦截。

function main(spreadsheetReport) { if (!spreadsheetReport._jhy_doRefresh) { spreadsheetReport._jhy_doRefresh = spreadsheetReport.doRefresh; } spreadsheetReport.doRefresh = function(fromButton, delayMask) { // 根据参数名称获取参数值 // 结束日期不早于开始日期 var endtime = new Date(spreadsheetReport.getParameterValue("结束日期 2").replace(/\-/g, "/")); var starttime = new Date(spreadsheetReport.getParameterValue("开始日期 2").replace(/\-/g, "/")); if (endtime < starttime) { setTimeout(function() { alert("结束时间不能早于起始时间"); }, 100); return; } // 结束日期不大于开始日期 90 天 if (endtime.getTime() - starttime.getTime() > 1000 * 3600 * 24 * 90) { setTimeout(function() { alert("两个参数的差不能超过 90 天"); }, 100); return; } this._jhy_doRefresh(fromButton, delayMask); }; }

逻辑说明：开头那个if (!spreadsheetReport._jhy_doRefresh)是防重复包装的关键——它把原始doRefresh存到一个自定义属性上，只在第一次执行时保存。如果不加这个判断，宏每次渲染都包一层，刷新一次套一层，几次之后点一下刷新会触发多次查询，这就是典型的“越用越慢”血泪经验。中间两段校验分别处理“结束早于开始”和“跨度超 90 天”，命中就alert并return，不调用原始刷新。最后一行this._jhy_doRefresh(fromButton, delayMask)才是放行，注意这里用this而不是spreadsheetReport，因为函数被挂到了实例上。

参数说明：getParameterValue("结束日期 2")里的参数名必须和报表里定义的参数名完全一致，包括空格和数字后缀，文档里带“2”说明参数名本身就有后缀，抄的时候别自作主张去掉。replace(/\-/g, "/")是把2024-01-01转成2024/01/01，因为部分环境下new Date("2024-01-01")的解析行为不一致，转斜杠是稳妥做法。1000 * 3600 * 24 * 90是毫秒数换算，90 天写成这个乘积比写死7776000000可读性好，改天数只改最后的 90。

4.2 参数名、日期格式和 90 天阈值的三个可调点

这段宏抄回去能不能跑，取决于三个可调点。第一是参数名，结束日期 2和开始日期 2必须换成你报表里的实际参数名，大小写、空格、后缀都要对，错一个字getParameterValue就返回空，new Date("")得到 Invalid Date，比较结果永远是 false，校验形同虚设。第二是日期格式，如果你的参数返回的是2024/01/01已经带斜杠，replace不会报错但也没必要；如果返回带时间戳，new Date也能吃，但跨度计算会把时分秒算进去，90 天边界可能差几小时，需要的话在比较前把时间归零。

第三是阈值，90 天是需求给的，但代码里这个数出现在两处：一处是1000 * 3600 * 24 * 90，一处是提示文案“不能超过 90 天”。改阈值时两处都要改，只改代码不改文案，用户看到的提示和实际规则对不上，这种不一致在验收时最容易被挑出来。我一般会把天数提成一个变量放函数顶部，两处都引用它，改一处生效。

提示：setTimeout(..., 100)包住alert是为了让弹窗在刷新流程之外执行，避免阻塞渲染线程导致弹窗和遮罩打架。这个 100 毫秒不用调，调小了偶尔弹不出来，调大了感觉卡顿。

4.3 校验通过后才放行刷新的执行链路

把这段宏放回整体流程看，它的执行链路是：用户点查询或改参数触发刷新 → 框架调用被重写的doRefresh→ 取两个参数值 → 两道校验 → 任一失败弹窗并return→ 都通过才调原始doRefresh真正查数。这个链路的价值在于“拦截在查询之前”，失败时不会产生一次无效查询，对数据源压力大的报表很实在。

要注意的是，这段宏只校验参数，不负责参数控件的默认值。如果用户第一次打开报表时参数是空的，getParameterValue返回空串，new Date("")是 Invalid Date，两个比较都是 false，校验直接放行，然后带着空参数去查数。所以空值场景要么在参数定义里设默认值，要么在宏里加一段空值判断提前拦。文档没写这块，但实际项目里空参数是高频问题，补一段if (!starttime || !endtime) return;之类的保护更稳。

5. 参数排版与预览发布：一行不超过 6 个的排版约束

5.1 参数排版的平均分配原则与两行布局

参数排版文档给了一条很具体的约束：筛选项居左，每行尽可能平均分配，一行不超过 6 个，如果是两行，第二行至少保留 2 个。这条规则不是审美偏好，是可用性底线——一行塞 7 个以上参数，控件会被压得很窄，日期选择器弹出来都点不准；两行布局第二行只剩 1 个，视觉上像被遗弃的孤儿，用户扫视时容易漏掉。

落地时我一般先把参数按使用频率排序，高频的放第一行左侧，低频的往后放。然后按“每行不超过 6 个”切行，切完检查第二行数量，少于 2 个就把第一行最后一个挪下来，或者把某个参数改成默认折叠。居左这条也要守，参数区整体左对齐，右侧留白给“查询”“重置”按钮，别让参数和按钮挤在一起。

排版改完要连着预览看两遍：一遍看默认状态，一遍把参数值都填上看控件会不会因为内容变长而换行。日期控件填了值之后宽度会变，原本一行 6 个可能变成 5 个半，这种细节只有预览才看得出来。

5.2 预览发布前必须过的检查项

预览发布是最后一步，但别把它当成点一下按钮。发布前我固定过一遍清单：冻结行号对不对、隔行颜色有没有串到表头、列宽自适应后有没有列被撑爆、参数校验两个分支都试过、参数排版在默认和填值两种状态下都不换行。这几项里任何一项没过，发布出去就是给用户添堵。

预览时重点看两个场景：一是把结束日期选到开始日期之前，确认弹窗文案正确且没有触发查询；二是把跨度选到 91 天，确认第二个弹窗生效。这两个场景过了，参数校验才算真跑通。列宽这块在预览里滚动一下，看冻结表头是否稳定、有没有列宽突变。

发布后如果发现样式和预览不一致，优先查模板引用那步是不是改过冻结行或删过空白行，因为发布走的是服务端渲染，模板结构变了渲染结果就变。这类问题回头改模板比在发布端调样式快得多。

6. 把这套宏放进版本管理：我的复用与回归习惯

这套文档里的两段宏——列宽自适应和参数校验——我后来都收进了一个公共脚本片段库，按报表类型分文件存，新报表直接引用而不是每次从文档里复制。这么做的好处是改一处能同步到所有引用它的报表，坏处是改错一处会连累一批，所以每次改动我都强制走一遍回归：找一张列多的报表验列宽、找一张带日期参数的报表验两个校验分支。

复用时有几个细节值得记下来。列宽自适应那段，maxDisplayRange.columnCount在数据为空时可能返回 0，autoFitColumns(0, 0)虽然不报错但也没效果，所以我在公共片段里加了一句if (counts <= 0) return;。参数校验那段，防重复包装的_jhy_doRefresh属性名带了个前缀，这是为了避免和框架或其他宏的属性撞名，你自己改的时候前缀可以换但别去掉，裸用_doRefresh撞上的概率不低。

回归验证我一般用一张对照表来记，避免凭记忆：

这张表我每次改公共片段都过一遍，十分钟的事，能挡掉大部分“改完这个坏了那个”的翻车。从那以后我每次往片段库里加宏，都强制先写一行回归项再写代码，不然改的时候爽、验的时候抓瞎。希望帮到你。

本文还有配套的精品资源，点击获取