企业官网建设流程全解析

做Java后端的人多少都碰过这套组合：若依管权限，积木报表出图表。但把两个东西拼在一起的时候，最难受的不是报表样式怎么调，而是Token安全校验怎么打通。我也是一路从“页面404”踩到“导出Excel报错”，最后把整套流程完整跑通，从依赖引入到Token解析，把积木报表的鉴权逻辑摸了个底朝天。这篇就按实战顺序，把方案怎么选、Token怎么传、坑都在哪儿，一次性写清楚，给正在折腾“若依+积木报表”的朋友做个参考。

1. 项目背景与整体方案设计

1.1 为什么选若依+积木报表这个组合

若依（RuoYi-Vue）在国内Java后端圈子里的占有率不用多说，前后端分离、RBAC权限模型、代码生成器这些都是现成的，拿来改改就能用，特别适合中后台管理系统快速落地。积木报表（JimuReport）则是一个纯Java的开源报表工具，支持在线设计报表、图表、填报和打印，最大的优势是集成成本低——引入一个starter，配个数据源，就能在项目里直接用可视化拖拽的方式出报表。

把两者组合起来，核心诉求就一句话：复用若依的用户体系和权限控制，让报表功能成为系统内部的一个模块，而不是一个独立的、需要单独登录的“孤岛”。如果放任积木报表自带登录页，用户每次看报表都得再输一次账号，管理层根本不会接受这种体验。那就必须在集成的同时，把若依的Token体系延伸到积木报表的请求链路上。

这里先给结论：积木报表不是不能直接配个iframe地址用，但一旦涉及权限控制和用户身份隔离，iframe方案基本就是给自己埋雷。正确做法是后端集成加Token校验统一处理。后面会详细展开。

1.2 一个容易被忽视的安全问题

很多人在集成时只关注“报表能不能显示出来”，忽略了身份认证的闭环。积木报表自带一套登录机制，如果不做任何处理，它的后台接口、报表数据接口默认是“只要过了积木自己的登录就能访问”。这就意味着：攻击者如果拿到了积木报表的访问地址，完全可以绕过若依直接访问报表后台，甚至通过报表数据接口拖库。

所以集成方案的底线要求是：

• 积木报表自带登录页不能暴露给最终用户；
• 积木报表的所有数据接口必须经过若依的Token校验；
• 用户只能通过若依登录后获得的Token访问报表数据；
• 不同用户看到的数据范围，最好还能根据若依的角色/部门做数据权限隔离。

后面第3章会重点说Token校验怎么落到代码里，这里先不展开了。

1.3 两种集成路线的取舍

在实际动手前，先想清楚走哪条路，能省掉后面大量的返工。

路线的本质区别在于：积木报表是独立部署，还是作为一个模块打包进若依项目。

我在实际项目中直接选了“后端模块集成”，把积木报表当做一个普通的Spring Boot Starter引入到若依工程中。这样报表的Controller和若依的Controller跑在同一个Servlet上下文里，Token校验的过滤器天然覆盖到所有请求，不存在跨域和Cookie作用域的问题。维护成本也最低，一台服务器把前后端和报表全包了。

2. 依赖引入与项目结构改造

2.1 依赖版本怎么选才不打架

积木报表的Spring Boot Starter在Maven中央仓库有正式版本，引入方式很简单，但版本选择不能拍脑袋。这里有一个需要特别留意的坑：积木报表依赖的Spring Boot版本、Mybatis-Plus版本和若依自带的版本不一定一致。

以我用的若依Vue 3.8.x为例，它内置的Spring Boot是2.5.x、Mybatis-Plus是3.4.x。积木报表1.6.0以上的版本，对这些基础组件的兼容性还可以，但POI的版本经常发生冲突。积木报表为了支持Excel导出，内部依赖了Apache POI 4.1.2，而若依的代码生成器或其他依赖可能会引入更高版本的POI，这时候Maven的依赖仲裁规则就可能把高版本或低版本覆盖掉，导致启动时报出各种NoSuchMethodError。

一个稳妥的做法是：引入积木报表starter时，把它的传递依赖先排除掉，再在项目里显式声明统一的版本号。这里给出我最终采用的pom片段。

<!-- 积木报表 starter --> <dependency> <groupId>org.jeecgframework.jimureport</groupId> <artifactId>jimureport-spring-boot-starter</artifactId> <version>1.6.4</version> <exclusions> <exclusion> <groupId>org.apache.poi</groupId> <artifactId>poi</artifactId> </exclusion> <exclusion> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> </exclusion> <exclusion> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml-schemas</artifactId> </exclusion> </exclusions> </dependency> <!-- 统一声明 POI 版本 --> <dependency> <groupId>org.apache.poi</groupId> <artifactId>poi</artifactId> <version>4.1.2</version> </dependency> <dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>4.1.2</version> </dependency>

这里把POI统一固定为4.1.2，是因为积木报表对4.1.2的兼容性最稳。如果你项目里其他模块强依赖POI 5.x，那就以实际测试为准，但一定要保证积木报表的Excel导入导出功能能正常跑通。

2.2 排除自动配置冲突

积木报表starter有一个让人头疼的地方，它会自动装配自己的数据源和Mybatis-Plus相关配置。如果不加干预，启动时可能报“Failed to configure a DataSource”或者和若依的数据源配置冲突。

解决方式是在若依的启动类上排除掉积木报表的数据源自动配置类。

@SpringBootApplication(exclude = { org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration.class, org.jeecg.modules.jmreport.config.JmReportDataSourceConfig.class }) public class RuoYiApplication { public static void main(String[] args) { SpringApplication.run(RuoYiApplication.class, args); } }

具体排除哪个配置类，取决于你引入的积木报表版本。建议在IDE里搜索一下JmReportDataSourceConfig这个类是否存在，不存在就换一个排除目标。这里我提供一个更通用的做法：不在启动类上排除，而是直接在application.yml里把积木报表的数据源指向若依的主数据源。

jimureport: datasource: # 使用默认数据源，不单独配置 type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: ${spring.datasource.druid.master.url} username: ${spring.datasource.druid.master.username} password: ${spring.datasource.druid.master.password}

这样积木报表直接复用若依的MySQL连接，数据源冲突的问题基本能绕开。注意：如果你使用多数据源，积木报表默认连的是master数据源，需要给报表单独指定数据源时，再在积木的后台配置里动态添加数据源即可。

2.3 菜单挂载的三种方式

报表后端集成进来了，前端怎么显示？我试过三种方式，逐一说明优劣。

方式一：iframe地址直连。菜单URL直接填积木报表的访问地址，比如/jmreport/index。这种方式配置最快，但它会绕过若依的Token认证，因为iframe加载的是一个全新的页面请求，请求头里不会自动带上若依的Authorization头。结果就是，用户要么看到积木报表自带的登录页，要么因为未登录被拦截。

方式二：后端接口返回报表地址，前端跳转。后端写一个接口，在接口里校验Token，通过后返回积木报表的页面地址，前台用window.open打开。这种比方式一强一点，但Token一旦过期，报表页面里的后续接口请求仍然过不了认证。

方式三：前端页面加载完毕后，用Axios携带Token请求积木报表的接口，拿到报表页面数据后，再动态渲染。这种是正路，它把积木报表的页面访问完全纳入若依的前端路由体系，Token在请求头里统一携带。

最终我采用的是“方式二+方式三”的混合版本：页面上直接嵌入积木报表的iframe，但iframe的src不是静态地址，而是走了一个带Token参数的转发接口。积木报表本身支持token参数，后端在转发时把若依的Token拼在URL里，积木报表收到Token后会调用我们自定义的校验服务（第3章细说）。这样既保留了积木报表在线设计器的完整交互能力，又绕过了它的登录页。

@GetMapping("/report/open") public String openReport(String reportCode, HttpServletRequest request) { // 校验当前用户是否已登录 String token = request.getHeader("Authorization"); if (!StringUtils.hasText(token)) { throw new ServiceException("未登录"); } LoginUser loginUser = tokenService.getLoginUser(token.replace("Bearer ", "")); if (loginUser == null) { throw new ServiceException("Token已失效，请重新登录"); } // 拼接带 token 参数的报表地址 return "redirect:/jmreport/design/" + reportCode + "?token=" + token.replace("Bearer ", ""); }

注意：Token放在URL参数里有被日志记录的风险，所以这里我建议给积木报表单独加一个Header参数读取逻辑，能不用URL传就不传。积木报表1.6.0以上版本支持从Header里读token，配置一下即可。

2.4 菜单权限和积木报表角色绑定

若依有角色、菜单、权限点的完整体系。积木报表后台也有自己的角色体系，如果放任不管，会出现“一个用户在若依里没有报表权限，却依然能通过积木报表后台看到所有报表”的漏洞。

我的做法是在若依的菜单权限点控制入口，同时把积木报表的角色与若依的角色做一层映射。具体来说，在若依里创建“报表管理员”“报表普通用户”等角色，分配对应的菜单权限；然后通过积木报表的接口，为每个登录用户创建或关联一个同名的积木用户，报表的授权权限交给该积木用户。这个过程在用户第一次打开报表页面时自动完成。

// 用户第一次访问时，自动同步为积木报表用户 JmReportUserService userService = SpringContextUtils.getBean(JmReportUserService.class); JmReportUser reportUser = userService.getUserByName(username); if (reportUser == null) { reportUser = new JmReportUser(); reportUser.setUsername(username); reportUser.setRealname(user.getNickName()); userService.addUser(reportUser); }

3. Token安全校验全链路设计

3.1 若依的JWT认证体系速览

先说若依自身的Token机制，不要一上来就写积木报表，基础不一样的话后面全是空谈。

若依使用的是Spring Security + JWT（JSON Web Token）的无状态认证方案。用户登录成功后，后端生成一个包含用户ID、用户名、过期时间等信息的JWT，通过Authorization: Bearer <token>的Header传递给前端。若依的TokenFilter过滤器会拦截所有API请求，解析Header中的Token，调用TokenService#getLoginUser方法从Redis中读取用户信息，并放入Spring Security的SecurityContext中。

之所以用Redis，是因为若依把JWT和登录会话做了绑定。JWT本身虽然无状态，但如果用户修改密码、被管理员踢下线，若依需要能立即让该Token失效。所以它的逻辑是：JWT里只存一个随机UUID作为key，真正的用户会话数据放在Redis里，过期时间以Redis里的为最终判断。这也是它叫“无状态JWT+Redis会话”的混合方案。

搞懂这个之后，积木报表的Token校验也就清晰了：我们只需要拿到积木报表请求中携带的Token，然后调用若依的TokenService#getLoginUser去Redis里查这个用户是否还存在、是否过期。查到了就说明用户是合法登录的，查不到就拒绝访问。

3.2 积木报表的鉴权扩展点

积木报表不是完全没有考虑集成场景。它在设计上留了几个扩展口子，其中最关键的是JimuReportTokenServiceI这个接口。官方的说明是：实现这个接口后，积木报表的请求在访问数据接口时，会自动调用实现类里的customToken方法，由外部系统来完成Token的校验和用户身份转换。

这个接口是打通两套权限体系的关键。注意，实现类必须注册为Spring Bean，积木报表启动时会自动注入。如果发现你写的实现类没生效，大概率是这个原因。

接口结构大致是这样的：

public interface JimuReportTokenServiceI { /** * 自定义Token校验 * @param token 请求中携带的token * @return 返回用户标识 */ String customToken(String token); }

积木报表内部拿到customToken的返回值后，会用这个返回值去识别当前用户是谁，并把用户信息关联到报表操作上。所以我们只需要在这个接口实现里，把若依的Token解析逻辑套进去即可。

3.3 自定义Token校验器的完整实现

这一步是整个集成的核心，代码不多，但逻辑必须严谨。以下是我在生产环境使用的实现版本，直接写在了若依框架的ruoyi-admin模块里。

@Component public class JimuTokenServiceImpl implements JimuReportTokenServiceI { private static final Logger log = LoggerFactory.getLogger(JimuTokenServiceImpl.class); @Autowired private TokenService tokenService; @Override public String customToken(String token) { // 容错处理：部分场景可能会传空token if (!StringUtils.hasText(token)) { throw new ServiceException("未获取到有效的Token，请重新登录"); } // 去掉前缀，兼容带 Bearer 的写法 String realToken = token.startsWith("Bearer ") ? token.substring(7) : token; // 调用若依的TokenService校验Token LoginUser loginUser = tokenService.getLoginUser(realToken); if (loginUser == null) { log.warn("[积木报表] Token校验失败，token={}", realToken.substring(0, Math.min(10, realToken.length())) + "..."); throw new ServiceException("登录状态已过期，请重新登录"); } // 校验通过，返回用户名作为积木报表的用户标识 return loginUser.getUsername(); } }

这段代码有几点值得展开：

第一，为什么要在实现类里重新拿一遍loginUser？因为积木报表的请求链路和若依的Spring Security过滤器链路不是完全绑定的。如果只是依靠若依的TokenFilter先过滤，再进入积木报表的Controller，有个顺序问题。直接在customToken里调用tokenService.getLoginUser是最牢靠的，它从Redis里取数据，即使过滤器顺序有变动，这里也能独立完成校验。

第二，loginUser.getUsername()返回值的含义。积木报表拿到这个用户名后，会用它在自己的用户表里查找或创建一条记录，之后该用户对报表的增删改查权限，都由积木报表自身的权限体系控制。这里有个容易踩的坑：如果你返回的是一段随机字符串，积木报表每次都会认为是一个新用户，已有的角色授权全部失效。所以建议返回稳定不变的若依用户名。

第三，Token前缀兼容。积木报表如果需要Header方式传Token，可能会收到带Bearer前缀的值。我在代码里做了剥离处理，避免因为多一个前缀就把Token判失败。

3.4 白名单与匿名访问控制

Token校验既然要做，就得想清楚哪些路径放行、哪些路径必须拦截。积木报表有很多内置的静态资源、验证码接口、字体文件等，这些不应该走登录校验，否则会拖慢首次加载速度。

我建议把以下路径加入若依的匿名访问白名单：

security: ignore: whites: - "/jmreport/eye/**" - "/jmreport/static/**" - "/jmreport/css/**" - "/jmreport/js/**" - "/jmreport/images/**" - "/jmreport/font/**"

同时要注意，不能把积木报表的登录接口放行。积木报表默认的登录路径是/jmreport/login，如果它被放行，攻击者还是能通过直接访问这个路径进入积木报表自己的登录页，绕过若依。最直接的办法：把这个路径拦截掉，或者干脆把积木报表的登录开关关闭。

在积木报表的配置文件里，有一个开关可以启用外部Token校验模式：

jimureport: auth: # 启用外部校验 enabled: true # 关闭自带登录页 loginPageEnabled: false

这个配置项在不同小版本里名称略有差异，如果发现无效，就检查一下当前版本的源码里JimuReportConfig这个类有哪些配置字段。实际踩坑之后我的建议是：不要依赖这个开关，直接在若依的SecurityConfig里把积木报表的自带登录接口加入拦截列表。

3.5 Token过期、续期与用户注销

Token会过期，过期了怎么办？这是生产环境一定会遇到的问题。若依的Token默认过期时间是30分钟（以Redis为准），如果用户在前台停留时间超过30分钟，点击报表时Token已经失效，那么积木报表的请求就会因为Token校验失败而弹出登录过期提示。

解决思路有两种。

思路一：前端在拿到若依Token后，定时调用刷新接口续期。若依本身有刷新逻辑，前端request.js里可以判断响应码，收到401时自动调用刷新接口换新Token，然后再重新发起报表请求。

思路二：将若依Token的过期时间调长。这个方法简单，但降低了安全性，Token一旦泄露，风险窗口期会很长。我建议不要为了报表而全局调长Token过期时间。

更好的做法是实现一个独立的短Token：后端在报表转发接口里，生成一个有效期只有3分钟的临时票据，拼在报表URL中。积木报表在3分钟内的请求都凭这个短票据访问数据接口。这样即使这个票据被打到日志里，攻击者能利用的时间窗口也很窄。

// 生成短期访问票据 String tempTicket = UUID.randomUUID().toString().replace("-", ""); redisCache.setCacheObject("report:ticket:" + tempTicket, loginUser.getUsername(), 3, TimeUnit.MINUTES); // 拼接报表地址 return "redirect:/jmreport/design/" + reportCode + "?ticket=" + tempTicket;

在customToken里优先校验ticket，再回退到校验Bearer Token：

@Override public String customToken(String token) { String username = redisCache.getCacheObject("report:ticket:" + token); if (StringUtils.hasText(username)) { return username; } // 回退到 JWT 校验 LoginUser loginUser = tokenService.getLoginUser(token); if (loginUser == null) { throw new ServiceException("登录状态已过期，请重新登录"); } return loginUser.getUsername(); }

用户注销场景也要注意。若依退出登录时，会把Redis里的会话数据删除，同时前端会清除本地的Token。但积木报表内部可能会有自己的缓存用户信息，比如在报表页面停留时积木的Session还会保持一段时间。这个不属于越权漏洞，但确实会造成“若依退了，报表页还能看几分钟”的观感问题。如果要彻底解决，得在积木报表的请求链路里每次都校验Token，不允许它用Session缓存。

4. 实操过程与核心环节实现

4.1 前端路由与请求拦截

后端配置完成后，前端也要同步改。若依Vue项目的utils/request.js里封装了Axios实例，默认会在请求头带上Authorization: Bearer <token>。这个逻辑对普通API接口有效，但积木报表通过iframe加载时，iframe内部的AJAX请求并不会自动携带这个Header。

所以要解决两个前端问题：一是在进入报表页面之前确保用户已登录；二是把Token通过安全的方式传给积木报表。

前端嵌入报表页面的核心代码，放到一个新建的ReportIndex.vue组件里。

<template> <div class="report-container"> <iframe :src="reportUrl" class="report-frame" v-if="reportUrl" /> <a-spin v-else tip="报表加载中..." /> </div> </template> <script setup> import { ref } from 'vue'; import { getReportAccessUrl } from '@/api/report'; const reportUrl = ref(''); function openReport(reportCode) { // 去掉多余参数，防止意外传入外部地址 const code = String(reportCode || '').trim(); if (!code) { this.$modal.msgError('缺少报表编码'); return; } getReportAccessUrl({ reportCode: code }) .then(res => { // 后端返回带票据的报表地址 reportUrl.value = res.data; }) .catch(() => { this.$modal.msgError('报表打开失败，请检查登录状态'); }); } </script>

注意一个绕不开的问题：iframe里的积木报表页面如果跨域调用后端接口，浏览器会拦截。我的方案里积木报表和若依跑在同一个域名和端口下，不存在跨域。如果你在集成时用了独立端口或者独立域名，就得在积木报表服务上配置CORS，允许若依前端域名跨域访问，并且允许携带Authorization头。这个配置一定要提前验证，因为它直接影响报表能否正常渲染。

4.2 数据权限：不同角色看不同数据

Token校验只是第一层，数据权限是第二层。积木报表的数据集可以直接写SQL，也可以配置成通过参数动态传值。要做好数据权限，最常用的方式是在积木报表的SQL数据集里声明一个自定义参数，比如${deptId}，然后在报表访问时，把这个参数的值换成当前用户所属的部门ID。

参数从哪来？还是从若依的LoginUser里取。我的做法是扩展一下上一章的customToken返回值，让积木报表能够拿到更完整的用户信息。这里需要看一下你所用的积木报表版本是否支持在customToken基础上再往报表上下文里塞参数。如果支持，可以这样实现：

@Override public String customToken(String token) { LoginUser loginUser = parseToken(token); if (loginUser == null) { throw new ServiceException("Token无效"); } // 把部门ID、角色ID写入积木报表的上下文 JmReportContextHolder.setParam("deptId", loginUser.getDeptId()); JmReportContextHolder.setParam("userId", loginUser.getUserId()); return loginUser.getUsername(); }

如果版本不支持，就在SQL里用积木报表内置的“系统参数”功能，通过数据权限拦截器拼SQL条件。不管哪种方式，核心思路是一致的：Token校验时把用户信息传递到报表数据层，让每条SQL都带上权限条件。

4.3 积木报表后台接口的额外保护

积木报表后台有很多管理端接口，比如saveReport、deleteReport、addDictItem。这些接口默认也需要登录才能操作。集成状态下，只要Token校验链路正确，这些接口都会被保护住。但有一个细节容易被忽略：积木报表的导出接口走得往往是文件流下载，有些下载请求在浏览器里是直接用地址栏访问的，并不会携带Authorization头，这时候就会触发Token校验失败。

为了解决文件下载时的Token丢失问题，我在积木报表的下载请求路径上额外加了一层GET参数传递。操作方式是：在前端的下载按钮点击事件里，手动拼接Token为请求参数，而不是依赖Header。

// 积木报表导出接口，手动拼接token function doExport(reportId, format) { const token = getToken(); const url = `/jmreport/view/${reportId}/export?format=${format}&token=${token}`; window.open(url, '_blank'); }

对应的，后端在解析时先读参数里的token，再读Header，保证两条通道都能校验通过。

4.4 表单设计器动态脚本的XSS防护

对症下药说安全。热搜词里提到了“存储型XSS”，这个在积木报表的表单设计器里要特别留意。积木报表支持在表单设计器中配置动态脚本，理论上可以在报表页面中执行JavaScript。如果这个功能开放给了不可信用户，攻击者在设计报表的时候写入恶意脚本，其他用户打开这张报表时就会执行脚本，形成存储型XSS。

我的建议是：

• 积木报表的管理员仅限系统管理员角色使用，不要给普通用户开放报表设计权限；
• 如果业务上必须开放，需要在积木报表的数据字典、数据集SQL输入处做好输入校验和转义；
• 若依框架自带的XssFilter默认过滤表单字段，但对积木报表的动态脚本，规则要单独评估，必要时在积木报表的配置项中关闭不必要的动态脚本能力。

5. 高频踩坑实录与排查技巧

5.1 导出Excel报错：could not initialize class POI

这个报错几乎每个集成积木报表的人都遇到过，属于POI类库初始化失败。我遇到的场景是：环境里安装了高版本JDK，POI在创建XSSFWorkbook时需要用到JVM内置的XML解析器，因为某种模块访问限制导致初始化失败。

排查步骤：

1. 确认POI版本。检查mvn dependency:tree中poi-ooxml的版本是否与积木报表匹配。
2. 看有没有多个POI版本并存。如果既有4.1.2又有5.2.3，Maven仲裁后可能留下的是不兼容版本。
3. 检查JDK版本。POI 4.1.2对JDK 8/11支持良好，对更高版本可能出现模块限制问题。如果确认是JDK与POI不兼容，升级POI版本，并复测积木报表的导出功能。

mvn dependency:tree -Dincludes=org.apache.poi

如果输出多个版本的POI，则在pom里把其他依赖的传递依赖排除掉，只保留一个版本。这个操作我在第2章已经写了，实际操作时记得在jimureport-spring-boot-starter上排除，也在若依其他可能引入POI的模块上排查一遍。

5.2 报表页面404与菜单集成失败

若依是前后端分离架构，前端用Vue Router做路由。如果你新增了一个“报表管理”菜单，但点击之后是404，大概率是因为前端没有注册对应的路由组件，或者路由路径写错了。

正确注册路由的方式：在若依前端src/router/index.js里增加一个组件路由，组件路径指向刚才创建的ReportIndex.vue。同时要在菜单管理后台里配置路由地址，并开放视图权限。

还有一个隐蔽原因：积木报表的页面和若依的前端路由是两套体系，如果前端使用了history模式（去掉#的那种），当用户在浏览器里直接刷新报表页面时，请求会先到后端静态资源处理器，如果后端没有配置对应的通配转发，就会返回404。解决方式是配置一个后端路由兜底，把前端路由指向index.html，这个配置在Spring Boot里通常叫forward: /index.html的回退规则。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { // 前端 history 路由刷新兜底 registry.addViewController("/report/**").setViewName("forward:/index.html"); } }

注意，这个兜底规则不要覆盖API路径，否则会把/jmreport/**也兜出去。

5.3 Token失效与匿名访问

如果用户打开报表时偶尔成功偶尔失败，绝大多数情况下是Token时效性问题。前面提过，若依Token默认30分钟过期。用户停留超过30分钟后，在报表页面执行操作，积木报表拿到过期的Token，customToken抛异常，报表数据请求直接挂掉。

排查方法：

1. 在customToken方法里加日志，打印接收到的Token和校验结果。
2. 追踪Redis里这个Token对应的key是否还存在。
3. 看浏览器网络请求面板，观察报表请求是否携带了正确的Header或参数。

另一个场景是积木报表的某些静态资源接口不在若依过滤链范围内，导致浏览器直接访问时报401或302，但页面部分加载。这个问题可以通过给积木报表的静态资源路径加入匿名白名单解决，但要控制粒度，放行的路径越少越好。

5.4 表单设计器动态执行脚本与存储型XSS

再强调一次，积木报表表单设计器支持动态执行脚本，务必对脚本内容做校验。不要把整个报表设计器直接暴露给所有登录用户，只给可信管理员开放。若依自带的防XSS过滤器只对普通请求参数生效，积木报表的动态脚本处理走的是另一套逻辑，需要单独查阅当前版本的文档，确认是否支持关闭。

如果确实需要支持脚本，建议增加服务端白名单校验，只允许特定域名下的脚本执行，不允许alert、eval、fetch等危险函数。这个防线做在前端是不够的，攻击者可以绕过前端直接提交恶意数据，服务端必须做一层严格过滤。

6. 集成完成后的扩展方向

积木报表和若依打通Token校验只是第一步，真正到生产环境里，你会发现还有不少可以继续完善的地方。

一个是报表访问统计。积木报表自带访问统计，但它是独立于若依体系的。如果希望统计到每个用户在报表模块的操作记录，可以在customToken校验成功后，把用户访问报表的日志写入若依的操作日志表，这样后台审计能统一看到“谁在什么时候看了哪张报表”。

另一个是数据权限深度绑定。如果业务需要“省级账号只能看省级数据，市级账号只能看市级数据”，简单的Token校验就不够用了。需要在积木报表的数据集参数里，根据用户的部门ID、角色编码动态拼接过滤条件。这个思路我在前面第4章提过，实际做的时候，要把部门和角色编码统一维护成一套规则，避免一个项目里若依一套、积木一套。

还有一个方向是积木报表的异步导出。大数据量报表导出时，接口容易超时。建议把导出任务提交到线程池或消息队列，生成文件后再通过若依的通知中心推送下载链接。这个改造不复杂，但体验提升非常明显，用户不需要一直死死盯着浏览器等导出完成。

我个人的体会是：报表功能最怕的不是技术难，而是权限边界模糊。Token校验做扎实了，后续所有权限扩展都站在同一个地基上。如果这一步图省事，用了iframe白嫖地址或者干脆把积木报表的登录页露出来，后期报表越来越多、用户越来越多，再回头补安全会异常痛苦。先把Token闭环打通，后面的路就好走了很多。