企业官网建设流程全解析

1. 项目全景：不作秀的政务举报平台，到底该怎么搭

如果你对“市民之家民生政务举报交流平台”这个标题第一反应只是“又一个政府项目”，那可能就把它看小了。这类平台真正考验的不是CRUD，而是混合负载支撑、多端体验一致、跨部门协同的流程闭环。群众在上面举报占道经营、投诉噪声扰民、咨询办事材料，每一个动作背后都要有明确的流转路径、处理时限和可追溯记录。

项目从架构层面定调为：SpringBoot做业务主体、Vue做前端交互、SpringCloud微服务做模块拆分、分布式组件做能力支撑。不是为“微服务”而微服务，而是因为这类平台的业务天然分域：举报、交流、用户、通知、文件、网关，每一块都有自己的扩展节奏和资源消耗特征。与其让一个几十上百个Mapper塞在一起的单体包越滚越重，不如一开始就把边界划清楚。

这个项目适合三类人直接拿来当蓝本：准备做政务类毕业设计或面试项目的同学、想把老单体项目按业务域拆成微服务的在职开发、以及需要给非技术领导解释“为什么政务平台要上微服务”的架构汇报执行人。下面我围绕架构决策、模块落地、实战排坑三条线展开，把一些在网上找不到完整答案的细节一并补齐。

2. 为什么是微服务？一开始就值得想清楚的三个理由

很多人一看到“微服务”三个字就直接开干，结果第一周就被环境问题耗掉大半时间。我建议在写第一行代码之前，先从下面三个角度确认拆分是否真的划算。

2.1 业务边界是否真的“顺滑”

市民之家平台里，用户体系、举报工单、留言互动、附件存储、消息通知，这几块的业务语义差异足够大。举报工单关心的是状态流转和超时督办；交流区关心的是帖子的浏览量与热评排序；用户中心关心的是手机号验证、实名等级和角色权限。它们不像传统进销存那样有强事务粘连，天然适合拆开。

我当时的拆分落点是六个服务：网关服务（Spring Cloud Gateway）、认证与用户服务（Auth/User）、举报工单服务（Report）、交流互动服务（Community）、消息通知服务（Notice）、文件服务（File）。另外用Nacos做注册与配置中心，用Sentinel做流量防护，用Redis做缓存与分布式锁底座。

2.2 团队协作和发版节奏是否受益

微服务带来的一个隐性好处是“不同模块不同发版频率”。举报工单很可能每周都在调流程、加字段；交流社区隔三差五要调整列表缓存策略；文件服务上线后基本稳定。如果这些都在一个单体工程里，任何一个小改动都得整包回归、全量发布。拆完之后，各自独立构建、独立部署，互不拖累。实际项目里，Report服务一周发了五个版本，File服务两个月没动过，这对运维来说非常舒服。

2.3 资源伸缩能不能做到“指哪打哪”

政务类平台有个很突出的特点：突发流量来自事件驱动。某个电视节目曝光了一处环境污染问题，当晚举报量可能是平日的几十倍；而交流板块的流量高峰往往在晚间。单体应用只能整机扩容，成本高且浪费。拆成微服务后，可以单独给Report服务扩两个Pod、给Community服务加缓存节点，其他服务保持原样。

注意，微服务不是银弹。如果你的团队只有两三个人、业务量日均不过千，老老实实SpringBoot + Vue单体全栈反而更稳。拆微服务的前提是业务域足够清晰、团队有基础设施运维能力，否则光一个分布式事务就够头疼的。

3. 整体架构设计与技术选型要点

定好拆分粒度后，下一步是搭建一套能支撑“前端、网关、微服务、数据层、基础设施”完整链路的骨架。这里把各层选型逻辑说透，方便你复刻。

3.1 后端微服务核心组件搭配

Spring Boot负责业务开发主体，版本建议直接选2.7.x（配合Spring Cloud 2021.x或2022.x都较稳定），JDK用1.8或11均可。Spring Cloud的组件搭配我推荐这套经受过实战的组合：

Nacos在这里承担了两个角色：一是所有微服务启动时向它注册自己的IP和端口；二是把数据库连接、Redis地址、文件上传目录等公共配置放上去集中管理。改一处，所有服务动态感知，避免“改配置要逐个服务重启”的尴尬。

3.2 前端Vue架构与周边配套

前端最初选的Vue 2 + Element UI，后来考虑到新项目倾向，Vue 3 + Element Plus是更长远的选择。但无论哪个版本，脚手架结构都推荐保持一致：

• axios统一封装：统一处理token注入、错误码解析、401跳转登录。
• vue-router路由守卫：前置守卫里判断用户角色、权限标识，不同角色看到不同菜单。
• pinia（Vue 3）/vuex（Vue 2）管理全局状态：存用户信息、权限点、未读消息数。
• wangeditor或bytemd做交流区的富文本/Markdown编辑器；记得做XSS过滤，政务平台最怕脚本注入。
• ECharts做管理端的数据统计面板，举报类型占比、处理时效趋势都能直接展示。

实际项目中，前端最容易踩的坑不是组件难写，而是接口联调规范。团队里一定要在项目初期定好HTTP状态码、业务状态码、分页参数风格，否则前端天天在适配各服务返回结构。我们当时的做法：所有服务返回值统一是{code, message, data}结构，code为200表示成功，否则为业务异常码，前端只需拦截code统一处理。

3.3 数据存储与文件存储

数据库选了MySQL 8.x，按业务域拆库：user_db、report_db、community_db、notice_db，保持数据域自治，不跨库关联查询。跨服务需要的数据通过OpenFeign拉取。Redis在这里有三个用途：

• 缓存热点数据（交流区帖子列表、首页举报分类统计）。
• 存放验证码（图形验证码、短信验证码都设置过期时间）。
• 做分布式锁（用户重复提交举报时防抖，抽奖/限量场景防超发）。

文件服务用的是MinIO，原因是国产化适配容易、部署轻量、兼容S3协议。后面第5章会专门讲MinIO接入SpringBoot的完整过程。

4. 核心业务流程设计与状态机落地

架构搭好了，平台真正难写的是业务。这里挑选四条主线展开：举报流程、交流互动、消息通知、数据看板。每一条都有值得细抠的地方。

4.1 举报流程：不只是一张“表单提交”

举报工单是本平台最重要的业务流，绝不是“用户提交 -> 管理员处理”这样两步走。它需要覆盖完整的生命周期：待受理、已受理、处理中、已办结、已驳回、已撤销。

我的实现方案是引入状态机机制，而不是把状态字段散落在业务代码里。在Report服务里建一张report_status_log表，每次流转记录“旧状态、新状态、操作人、操作时间、备注”，这样事后追责、超时督办、统计分析都有据可依。

核心状态流转约束：

• 用户提交后状态为PENDING（待受理），用户可以主动撤销，时间窗口为24小时内。
• 受理人员将工单转为ACCEPTED（已受理），同时指定处理部门。
• 部门处理人受理后进入PROCESSING（处理中），可以多次补充处理进度。
• 完成处理后提交DONE（已办结），系统自动给举报人发通知。
• 如果事实不成立或不属于受理范围，受理人员可以REJECTED（已驳回），必须填写驳回原因。
• 若在PENDING阶段用户撤销或超过时限，进入CANCELLED（已撤销）。

状态流转图不建议写死在代码if-else里。用一张配置表来存储流转规则，比如“哪些角色在哪个状态下允许执行哪个动作”。这类政务平台后续大概率会调整业务流程，配置化能大幅度减少改代码的频率。

实操注意：每个状态变更都要同时写业务表和日志表，两者务必在同一个本地事务里完成。因为是单个服务内部的本地事务，不需要引入分布式事务，千万不要把简单问题复杂化。

4.2 交流互动：热门帖、敏感词与XSS三座大山

交流社区如果做成一堆帖子叠在一起的feed流，就太浪费了。这里的关键点有三个：

热门帖子排序：不能每次查询都全表ORDER BY reply_count DESC。我当时的方案是：帖子表增加hot_score字段，通过定时任务每5分钟计算一次。计算公式参考了常见的热度算法：hot_score = (点赞数*2 + 评论数*3 + 浏览数*0.1) / pow((当前时间 - 发布时间)对应的小时数 + 2, 1.5)。算好后写回Redis zset，查询时直接按score取前N条，性能非常稳定。

敏感词过滤：政务交流平台不能有漏网的违规内容。方案是维护一套敏感词库（可用开源的词库做基数），用DFA算法实现敏感词检测，命中后用*替换。注意检测要在发布帖子和回复时做，也别忘了用户昵称和头像签名这类边边角角的字段。

XSS防御：这个问题非常值得展开。整体策略是：

• 前端表单收集阶段就注意富文本过滤。
• 后端配置全局过滤器，对请求参数里的危险标签进行转义。
• 存储到库前再统一清洗一遍。

SpringBoot里实现全局XSS过滤器的一个核心思路是：继承OncePerRequestFilter，重写getInputStream和getParameter的读取逻辑，用Jsoup.clean()对内容做白名单过滤。网上能搜到不少实现，但90%的方案都只处理了getParameter，没处理JSON请求体。我们实际是同时覆盖了这两个路径，否则传{"content": "<script>"}照样能绕过防线。内容入库前后要做一遍转义和拦截，富文本仅允许p、span、img、a、strong、br等安全标签，script、iframe、object、link一律剔除。

4.3 消息通知：举报结果的“最后一公里”

用户举报之后，最关心的就是“有没有人处理”。消息通知服务专门负责把结果推给对应的用户。这里不直接调用短信或站内信接口，而是统一走消息中心：

• 用户提交举报成功后，Report服务发送一个REPORT_SUBMIT事件。
• 工单状态变化时，Report服务发送REPORT_STATUS_CHANGE事件。
• Notice服务监听事件落库，再异步调短信平台/微信公众号模板消息推送。

这里引申出一个很关键的微服务话题：分布式事务。举报状态变更与通知发送无法保证原子性，但我们不追求强一致。策略是本地消息表 + 定时补偿：Notice服务收到事件后先写本地消息表，在事务提交后再调用第三方推送。如果推送失败，定时任务扫描重推，最多重试三次。这就是“最终一致性”在真实项目里的实用打法，也是微服务面试时能讲出彩的点。

4.4 管理端数据看板：让报表服务“读”起来

市民之家的后台一定要有数据看板，否则领导看到的就是一个个孤立工单，无法掌握整体情况。

管理端看板包含：举报总量、日新增举报趋势、各类型占比饼图、处理时效分布、办结率排名。这些数据如果实时查业务库，用户量大一点就会拖垮主库。所以单独做了一个统计数据服务：定时从各业务库把数据聚合到统计表里，看板接口只查统计表。

定时任务方面，短周期（分钟级）用Spring Scheduled就够了，长周期重活可以用Quartz或xxl-job。考虑到当前项目规模，xxl-job是更合适的方案，它有可视化控制台，可以动态调整任务时间、手动触发执行，方便排查数据问题。

5. 核心实操：MinIO分布式文件服务接入与SpringBoot整合

标题里提到“分布式”，文件存储是避不开的环节。MinIO是一个兼容S3协议的对象存储服务，文件上传后以对象形式存储，天然支持多副本、多节点部署。整个接入流程并不复杂，这里把关键步骤与代码细节全部展示出来。

5.1 部署MinIO（还不需要深入到集群，但先留好扩展位）

生产环境建议至少两个节点，开发环境先用单机即可。单机启动命令：

mkdir -p /data/minio wget https://dl.min.io/server/minio/release/linux-amd64/minio chmod +x minio export MINIO_ROOT_USER=minioadmin export MINIO_ROOT_PASSWORD=your-strong-password ./minio server /data/minio --console-address ":9001"

注意新版MinIO的启动环境变量已经不再是MINIO_ACCESS_KEY或MINIO_SECRET_KEY，而要用MINIO_ROOT_USER与MINIO_ROOT_PASSWORD。9010端口是控制台地址，API端口默认9000。老教程里那一堆旧变量名容易误导人。

生产多节点集群时，命令形式类似./minio server --console-address ":9001" /data1 /data2 /data3 /data4，多个节点组成纠删码模式。这里不展开，但架构上预留好挂载目录即可。

5.2 SpringBoot整合MinIO依赖与配置

pom.xml中添加MinIO SDK：

<dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.5.7</version> </dependency>

在application.yml中配置：

minio: endpoint: http://192.168.1.100:9000 access-key: minioadmin secret-key: your-strong-password bucket-name: citizen-home

5.3 实现文件上传与访问路径转换

封装一个MinioService，核心代码：

@Service public class MinioService { @Resource private MinioClient minioClient; @Value("${minio.bucket-name}") private String bucketName; public String uploadFile(MultipartFile file, String module) { String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String objectName = module + "/" + UUID.randomUUID().toString().replace("-", "") + suffix; try { boolean found = minioClient.bucketExists(BucketExistsArgs.builder().bucket(bucketName).build()); if (!found) { minioClient.makeBucket(MakeBucketArgs.builder().bucket(bucketName).build()); } minioClient.putObject(PutObjectArgs.builder() .bucket(bucketName) .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); } catch (Exception e) { throw new BusinessException("文件上传失败"); } // 返回可直接访问的URL return minioEndpoint + "/" + bucketName + "/" + objectName; } }

创建MinioClient的配置类：

@Configuration public class MinioConfig { @Bean public MinioClient minioClient(MinioProperties properties) { return MinioClient.builder() .endpoint(properties.getEndpoint()) .credentials(properties.getAccessKey(), properties.getSecretKey()) .build(); } }

写文件用的对象名做了两层处理：外层按module/目录区分业务模块（举报附件、社区图片、头像），内层用UUID随机名。这样避免文件名冲突，更避免中文文件名可能导致的URL编解码问题。

常见问题：上传成功后图片打不开，控制台报“AccessDenied”。这不是代码问题，而是桶的访问权限。MinIO默认桶是私有的。如果希望图片URL能被浏览器直接访问，需要设置桶策略为download或public。开发环境可以这样操作，生产环境建议走短时效的预签名URL：

String presignedUrl = minioClient.getPresignedObjectUrl( GetPresignedObjectUrlArgs.builder() .method(Method.GET) .bucket(bucketName) .object(objectName) .expiry(7 * 24 * 3600) .build() );

5.4 MinIO与Nginx配合的细节

图片和视频的访问路径如果直接暴露MinIO的9000端口，既不安全也不美观。生产上建议在Nginx层做一层反向代理：

server { listen 9002; server_name file.citizen-home.local; location / { proxy_pass http://minio-server:9000; proxy_set_header Host $host; } }

这样外网统一入口是9002，内网MinIO端口不对外开放，安全性高很多。这件事看着基础，但很多项目上线后才发现，到时再改访问域名就要涉及存量数据里的URL替换了，非常被动。

6. 网关、鉴权与多人协作的工程化难题

微服务架构里，“入口统一”和“身份识别”是最先暴露问题的环节。很多初学者把网关当成刚转发就完事，结果后面登录态、权限校验、跨域全是坑。

6.1 Spring Cloud Gateway路由与鉴权过滤器

网关层承担三件事：路由转发、JWT校验、接口级权限判断。路由配置示例：

spring: cloud: gateway: routes: - id: report-route uri: lb://report-service predicates: - Path=/api/report/** - id: community-route uri: lb://community-service predicates: - Path=/api/community/**

注意lb://前缀，Spring Cloud Gateway会结合注册中心做负载均衡。给每个服务分配独立的URL前缀，能有效避免路由冲突。

网关鉴权用全局过滤器实现。核心逻辑：从请求头取Authorization，解码JWT后放入请求头传递给下游服务。下游服务统一约定从X-User-Id、X-User-Role等请求头里获取用户信息，而不是自己再解析一次JWT。这样既减轻下游服务负担，也避免“每个服务都重复解析token”的灾难。

@Component public class AuthGlobalFilter implements GlobalFilter, Ordered { @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request = exchange.getRequest(); // 放行登录注册、验证码等白名单路径 String path = request.getPath().value(); if (path.startsWith("/api/auth/login")) { return chain.filter(exchange); } String token = request.getHeaders().getFirst("Authorization"); // 解析JWT，设置用户信息到header Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); request.mutate() .header("X-User-Id", claims.get("userId").toString()) .header("X-User-Role", claims.get("role").toString()) .build(); return chain.filter(exchange.mutate().request(request).build()); } @Override public int getOrder() { return -100; } }

这里非常容易踩的坑是：网关传递请求头变量到下游，下游服务如果配置了网关心跳检查，会把自定义header过滤掉。解决方式有两种，一是网关里把原始请求头全部放行，二是下游服务做白名单配置。我建议采用后者，只信任网关放行的X-User-Id等白名单头，其他外部传入的一律忽略。

6.2 跨域配置：前端联调时最容易炸的点

网关层统一解决CORS问题。Spring Cloud Gateway里写一个CORS配置类：

@Configuration public class CorsConfig { @Bean public CorsWebFilter corsWebFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:8080"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsWebFilter(source); } }

千万别在前端项目里再单独配代理跨域，也不要同时在网关和各微服务里各配一遍CORS。跨域处理只允许出现在最外层网关一次。否则会出现“浏览器报CORS双重头”“Access-Control-Allow-Origin多次出现”的玄学错误。

6.3 服务间调用OpenFeign统一封装

服务间调用如果用RestTemplate，代码冗余且难维护。OpenFeign声明式客户端是目前的主流方案。定义如下：

@FeignClient(name = "file-service", path = "/api/file") public interface FileFeignClient { @PostMapping("/upload") R<FileInfoVO> upload(@RequestParam("file") MultipartFile file); }

注意两个细节：一是name对应注册中心的服务名，不是IP；二是Feign接口的@RequestParam如果传的是文件对象，消费方服务启动时要额外配置spring.servlet.multipart.enabled=true，否则会出现“Current request is not a multipart request”的报错。这个报错在网上常被误解成是消费方忘了加@EnableFeignClients，其实更多时候是Multipart未开启或方法参数位置不对。

7. 开发与部署的实操细节：从环境到上线踩过的坑

这部分是我最想写的内容，因为网上很少能一次讲全。每一步都是实际项目里真金白银趟出来的。

7.1 Windows本地如何跑通SpringCloud全家桶

很多人第一次搞微服务都被环境劝退。Windows本地开发，Nacos、Redis、MinIO都是自带启动脚本的工具，但内存开销不小。我的建议是：

• Nacos：使用startup.cmd -m standalone以单机模式启动，不要默认集群模式。
• Redis：用Windows版或者直接放在Docker Desktop里跑。
• MinIO：Windows版直接下载exe启动。
• 代码侧：所有微服务的配置统一从Nacos读取，本地环境单独建一个common.yaml，数据库连接设为127.0.0.1。

如果电脑内存只有16G，建议只启动必要的服务：Nacos、网关、认证中心、举报服务。其他服务按需启动。不要尝试一次全跑，光是JVM内存就占掉大半。

7.2 Docker Compose部署编排实战

生产环境我用Docker Compose做了整套编排，比K8s轻量得多，非常适合这个体量的政务项目。核心编排文件大概如下：

version: "3.8" services: nacos: image: nacos/nacos-server:v2.3.2 environment: MODE: standalone ports: - "8848:8848" - "9848:9848" redis: image: redis:7.0 ports: - "6379:6379" minio: image: minio/minio command: server /data --console-address ":9001" ports: - "9000:9000" - "9001:9001" gateway: build: ./gateway ports: - "8080:8080" depends_on: - nacos report-service: build: ./report-service depends_on: - nacos - mysql

注意Nacos v2.x之后默认会占用8848和9848两个端口，9848是gRPC端口。如果忘记放行9848，服务注册会出现“nacos failed to req api”的报错，但控制台看起来一切正常，非常迷惑。这也是Nacos 2.x区别于1.x最典型的坑。

7.3 项目上线前的安全检查清单

政务平台的安全红线比普通商用系统更严格。梳理几个必须做的事：

• 所有接口强制走HTTPS，网关层做HTTP自动跳转。
• 密码加密存储，推荐BCrypt，不要用MD5裸存。
• 接口防刷：核心接口加Sentinel流控规则，同一IP单位时间超限直接拒绝。
• 敏感数据脱敏：手机号、身份证号在前端展示时中间四位打码。
• 操作日志全量记录：谁在什么时间改了什么状态，必须可审计。
• 数据库备份脚本：备份保留至少30天，恢复演练每季度做一次。

访客提交的附件要主动做文件类型识别，不能只看扩展名。MultipartFile.getContentType()可以直接被伪造，务必配合服务端对文件头字节做二次校验。图片文件的起始字节是FF D8 FF，PDF是25 50 44 46，Word是D0 CF 11 E0。实战中，拦截截图能拦住八成恶意上传。

7.4 分布式锁，防重复举报和超时抢单

举报平台有个独特问题：用户手滑双击提交，或者恶意脚本无限刷新，同一时间可能会生成两条一模一样的工单。这个场景适合用Redis分布式锁解决。

String lockKey = "report:duplicate:" + userId + ":" + md5(content); Boolean lock = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(5)); if (Boolean.FALSE.equals(lock)) { throw new BusinessException("请勿重复提交"); } try { // 业务处理 } finally { redisTemplate.delete(lockKey); }

注意锁的有效期不能太短，否则业务还没执行完锁就过期了；也不能太长，否则真正的用户重复操作会等很久。5秒是针对单条举报落库+发事件的常规时间。还要注意，setIfAbsent本身是原子操作，不要用先get再set的方式做，否则并发场景下锁就形同虚设。

7.5 MinIO用到生产后，一次“图片全没了”的复盘

这里讲一个真实翻车案例。项目上线一个月后，发现历史举报附件全部打不开，控制台显示文件不存在。排查后确认：MinIO的数据盘做扩容时，运维直接把原来挂载的目录删掉并重建了。MinIO只在启动时指定数据目录，历史数据没有做迁移，数据就丢了。后面部署时特意加了一条规则：MinIO数据目录必须挂在持久化存储上，并且天天做增量备份。这个坑对任何人来说都值得记一笔，对象存储不等于数据保险箱，该备份的一定要备份。

8. 前端Vue落地实录：页面开发与接口联调经验

后端链路打通后，前端直接决定了项目演示效果。市民之家平台的前端分为用户端和管理端，我选了同一套Vue技术栈分别构建。

8.1 用户端页面结构与Vue Router设计

用户端页面结构：

• 首页：举报分类导航、热点问题、公告栏。
• 举报页：表单 + 材料上传 + 查询进度。
• 交流页：帖子列表、帖子详情、发布动态。
• 个人中心：我的举报、我的帖子、消息列表。

路由设计时我用了一层嵌套布局路由，整体结构清晰：

const routes = [ { path: "/", component: Layout, children: [ { path: "", component: HomeView }, { path: "report", component: ReportView }, { path: "community", component: CommunityView }, { path: "profile", component: ProfileView } ] } ];

路由守卫统一处理未登录跳转：

router.beforeEach((to, from, next) => { const token = localStorage.getItem("token"); if (to.meta.requiresAuth && !token) { next("/login"); } else { next(); } });

8.2 前端分页、状态管理与性能优化

交流社区的帖子列表是分页加载的，后台接口返回total和records。前端封装一个通用的分页组件后，各业务页面复用即可。为了避免每次翻页白屏，我用watch监听路由变化，使用keep-alive缓存列表页面，回退时不重新拉接口，体验上一个档次。

Vuex/Pinia里存储用户信息和权限点。比如用户是普通群众就显示“我要举报”，是管理员就显示“工单审核”。菜单权限交给后端返回的权限标识数组去过滤，不要在前端写死。之前遇到过一个尴尬问题：前端根据本地环境变量控制菜单显隐，生产环境没打包好，管理菜单暴露出去了。好在网关层的接口权限兜底拦住。前端权限只是体验优化，安全边界永远在后端。

8.3 Vue与SpringBoot联调时的心法

联调过程中前端最容易遇到的两个问题：跨域和Token过期。跨域问题在网关层统一解决后基本不出现；Token过期的处理则比较讲究轮询机制。我们需要在axios响应拦截器里统一判断401：

• 若当前请求返回401且不是刷新token接口，则调用刷新token接口。
• 刷新成功则原请求重放，失败则跳转登录页。

service.interceptors.response.use( response => response, error => { if (error.response.status === 401) { const refreshToken = localStorage.getItem("refresh_token"); if (refreshToken) { return refreshTokenRequest() .then(res => { localStorage.setItem("token", res.data.token); error.config.headers["Authorization"] = "Bearer " + res.data.token; return service(error.config); }) .catch(() => { router.push("/login"); }); } else { router.push("/login"); } } return Promise.reject(error); } );

配合这个逻辑，后端用户服务有必要预留刷新令牌接口，token有效期控制在30分钟，refresh_token有效期控制在7天，兼顾安全与体验。

9. 常见问题速查表：微服务与政务类项目排坑合集

把整个开发过程中踩过的坑整理成一张速查表，建议收藏，遇到同样问题时直接对照排查。

再补充一个容易被忽略的运维细节：微服务配置了重试之后，下游接口必须做好幂等。否则重复提交工单、重复充值这类操作很容易造成脏数据。幂等实现最简单的办法是查重：在业务表加唯一索引，或在数据库存储一个业务流水号字段，由上游生成，下游写入时做唯一约束，冲突即视为重复请求。

10. 项目演进的下一步：从能用走向好用

市民之家平台是一个典型的高并发场景较少的微服务项目，但从技术角度看，它具备了分布式架构的大部分基础组件。做完这版之后，有几条路值得继续扩展。

如果数据量涨上来，可以给举报工单数据做分库分表。当前分库是按业务域，下一步按时间分表，例如report_info_2026_01这种按月分表。定期归档历史数据到冷存储，热表只保留近六个月数据，查询性能会有明显改善。归档逻辑建议用定时任务每天执行一次，从业务库把超过180天的已办结工单迁走。

如果要做移动端，可以直接利用现有接口，开发小程序。服务端只需要补充一个微信登录获取openid的接口即可，路由和页面全部复用Vue的组件思路。政务类小程序审核比普通小程序严格，类目和资质文件要提前准备。

如果要做大屏展示，管理端看板的数据聚合服务可以直接提供一个专门的大屏接口，按维度汇总数据，前端用ECharts渲染。数据源依然来自统计表，不用去动业务主库。

从投入产出比看，优先做移动端适配价值最高。市民之家一大半用户都在手机上访问，PWA方案也行，但小程序在政务场景的体验和适配成本上更有优势。

另外在架构层面，还有几个值得投入的点：把Spring Cloud Gateway迁移到更高性能的云原生网关（如Kong或APISIX）以提升并发能力；链路追踪从“调用链靠肉眼翻日志”升级为接入SkyWalking，产出服务调用拓扑图；发布流程从手工docker compose升级为GitLab CI/CD流水线，执行测试、构建、发布一气呵成。这些都是微服务项目从“能用”走向“好用”的必经之路。

我个人在实际搭建中最大的体会是：这类项目最复杂的不是某个单独的技术点，而是技术栈非常多却要协调一致。SpringBoot、Vue、SpringCloud、MinIO、Redis、Nacos，每一层都有各自的版本坑和配置细节，组合起来就是指数级的复杂度。所以写代码之外，很重要的是维护一份“技术栈版本对照表”，把各组件版本、关键配置项、启动方式记录下来，不然过两个月再回头看，自己都不知道当时是怎么连通的。

最后分享一个简单但极其实用的小技巧：给所有微服务模块统一加上健康检查接口/actuator/health，网关和Nacos都能通过它判断服务实例是否存活。配置很简单，加依赖spring-boot-starter-actuator后，默认暴露/actuator/health即可。这个小改动在后续排查“某个服务注册了但调用总超时”的问题时帮了大忙。

如果这篇文章对你有帮助，建议照着架构图先搭一套简化版，把网关、一个业务服务、前端跑通，再逐渐补齐其他模块。微服务最怕一口气吃成胖子，先把最小闭环跑起来，后面每一块都是增量演进。