简介这是一套基于Vue与Spring Cloud构建的全栈式博客系统实战项目面向Java后端、前端及微服务架构学习者解决分布式系统开发、前后端分离实践与主流中间件集成等核心问题。资源包共1025个文件涵盖265个Java微服务模块代码、360个JavaScript/Vue前端逻辑、70个Vue组件、55个XML配置及23个YML微服务配置文件辅以SQL脚本、Docker部署脚本与详细设计文档含.docx说明整体压缩包91.44MB。已有647人学习下载项目完整实现高可用Eureka注册中心、Zuul网关、Feign负载调用、Redis缓存与分布式锁、RabbitMQ延迟队列、Elasticsearch全文检索及WebSocket实时通信并集成支付宝支付与v-charts数据可视化所有代码均带中文注释支持Docker一键部署扩展性强适合作为微服务架构学习、毕业设计或企业级项目参考。1. 项目概述与核心价值最近几年无论是技术社区还是个人开发者搭建一个属于自己的博客系统似乎成了一件“标配”的事情。这背后不仅仅是技术展示的需求更是一种深度思考与知识沉淀的仪式感。我见过很多朋友从最初的WordPress、Hexo静态博客到后来追求更个性化的前后端分离方案技术选型一直在迭代。今天我想和大家深入聊聊的就是一个基于Vue和Spring Cloud的现代化博客系统设计与实现。这不仅仅是一个增删改查的CRUD项目更是一个融合了前端工程化、后端微服务架构、服务治理与性能优化的综合性实践场。为什么是Vue Spring CloudVue以其渐进式的特性和友好的学习曲线成为了前端开发的主流选择之一其响应式数据绑定和组件化开发模式非常适合构建交互复杂、用户体验要求高的单页面应用SPA比如一个需要实时评论、动态内容加载的博客。而Spring Cloud作为Spring Boot的微服务“全家桶”它提供了一整套服务发现、配置管理、熔断限流、网关路由的解决方案。用这套组合拳来打造博客看似“杀鸡用牛刀”实则是对微服务理念一次绝佳的练兵。你能在这个过程中真切地体会到从单体应用到服务拆分、从直接调用到通过注册中心寻址、从单一数据源到分布式事务考量等一系列架构思想的落地。这个项目适合谁呢如果你是已经掌握了Vue和Spring Boot基础想向全栈和分布式系统设计迈进的初中级开发者那么这个项目会是一个完美的跳板。它涵盖了从前端路由、状态管理、组件封装到后端服务拆分、Feign声明式调用、Gateway统一网关、分布式文件存储等众多核心知识点。通过亲手实现它你获得的将不仅仅是一个能运行的博客更是一套应对复杂业务场景的架构思维和实战能力。接下来我会从设计思路拆解开始带你一步步走进这个系统的核心。2. 整体架构设计与技术选型考量当我们决定采用微服务架构来构建博客时首要任务就是厘清业务边界进行合理的服务划分。一个博客的核心功能模块相对清晰这为我们设计微服务提供了很好的基础。2.1 微服务拆分与领域模型设计传统的单体博客应用可能会把所有功能——文章管理、用户认证、评论、文件上传——都塞进一个庞大的工程里。而在微服务架构下我们遵循“高内聚、低耦合”的原则按业务领域进行拆分。在这个博客系统中我初步规划了以下几个核心微服务用户服务 (user-service)负责所有与用户相关的业务包括注册、登录、鉴权、个人信息管理。它是系统的门户也是安全的第一道防线。文章服务 (article-service)博客的核心负责文章的创建、编辑、发布、删除、查询列表、详情、按分类/标签筛选以及文章数据的统计如阅读量。评论服务 (comment-service)处理文章的评论功能包括发表评论、回复评论、评论列表查询、敏感词过滤等。将其独立出来是因为评论业务相对独立且可能面临较高的并发读写。文件服务 (file-service)统一管理图片、附件等静态资源的上传、存储、访问和删除。独立文件服务的好处是便于扩展存储策略如本地存储、FastDFS、OSS云存储并且不影响其他业务服务。搜索服务 (search-service)提供对文章标题、内容的全文检索功能。初期可以用数据库的LIKE查询简单实现后期可以无缝集成Elasticsearch来提升搜索体验和性能。除了这些业务服务微服务架构还离不开一系列基础设施组件也就是Spring Cloud的“五大组件”或其替代方案服务注册与发现 (Nacos / Eureka)我选择了Nacos。它不仅支持服务注册发现还集成了动态配置管理功能一个组件解决两个问题比Eureka更轻量、功能也更丰富。所有上述业务服务启动后都会向Nacos Server注册自己的服务名和实例地址。统一网关 (Spring Cloud Gateway)作为整个系统的唯一入口Gateway负责路由转发、权限校验结合JWT、限流熔断、请求日志记录等。例如所有以/api/article/**开头的请求都会被路由到article-service的某个实例上。声明式服务调用 (OpenFeign)用于服务间的远程调用。比如comment-service需要查询某条评论的作者信息它就可以通过Feign客户端调用user-service提供的接口像调用本地方法一样简单。负载均衡 (Spring Cloud LoadBalancer)Spring Cloud Greenwich版本后默认使用LoadBalancer替代了Ribbon。它与Feign或RestTemplate集成在调用服务时自动从Nacos获取服务实例列表并进行负载均衡如轮询。配置中心 (Nacos Config)将各个服务的配置数据库连接、Redis地址、开关参数等集中管理在Nacos中实现配置的动态刷新无需重启服务。注意服务拆分不是越细越好。过度拆分会带来分布式事务、网络延迟、运维复杂度飙升等问题。对于个人博客这类业务初期将核心领域拆分为4-5个服务是较为合理的。像“分类”、“标签”这类轻量级功能完全可以作为“文章服务”的一部分无需单独成服务。2.2 前后端分离与交互模式前端采用Vue 3 TypeScript Vite的组合。Vue 3的Composition API让逻辑组织更灵活TypeScript提供了强大的类型检查能有效减少运行时错误Vite则带来了极致的开发热更新体验。前后端通过RESTful API进行通信数据格式统一为JSON。前端通过Axios库封装统一的请求拦截器自动在请求头中携带JWT Token。后端Gateway或各个服务的拦截器会验证Token的有效性。这种模式清晰地将展示逻辑与业务逻辑分离前端可以独立部署后端API可以供多种客户端Web、移动端消费。在状态管理上对于博客这类项目并非所有状态都需要用到Vuex或Pinia。我的经验是仅将需要跨多个不相关组件共享的状态放入全局Store。例如用户的登录状态、个人资料信息。而文章列表、文章详情这类页面级状态使用组件自身的reactive或ref来管理就足够了这样更简单清晰。3. 前端Vue工程的核心实现细节前端工程是整个博客的门面用户体验的好坏直接在这里决定。我们不仅要实现功能更要关注代码结构、性能和维护性。3.1 项目初始化与工程化配置使用Vite创建项目是现在的首选npm create vuelatest。在初始化选项里勾选上TypeScript、Vue Router、Pinia状态管理、ESLint和Prettier。这为我们搭建了一个现代化、开箱即用的开发环境。工程目录结构的设计体现了关注点分离。我通常采用如下结构src/ ├── api/ # 所有后端API接口的封装按服务模块划分article.ts, user.ts ├── assets/ # 静态资源图片、字体、样式 ├── components/ # 公共组件Header, Footer, Sidebar, Loading ├── composables/ # Vue 3组合式函数如usePagination, useUpload ├── layouts/ # 布局组件DefaultLayout, AdminLayout ├── router/ # 路由配置 ├── stores/ # Pinia状态仓库userStore, appStore ├── styles/ # 全局样式、变量 ├── types/ # TypeScript类型定义 ├── utils/ # 工具函数request.ts封装axios, format.ts格式化工具 ├── views/ # 页面视图组件Home.vue, ArticleDetail.vue, Admin.vue └── main.ts在utils/request.ts中我们会封装Axios实例设置基础URL、超时时间并添加请求/响应拦截器。请求拦截器负责从Pinia或LocalStorage中获取Token并添加到Header响应拦截器则统一处理错误如401跳转登录页500弹出错误提示。3.2 路由设计与动态权限管理路由由Vue Router管理。我们需要区分前台路由和后台管理路由。在router/index.ts中定义const routes: RouteRecordRaw[] [ { path: /, component: DefaultLayout, // 前台布局 children: [ { path: , component: HomeView, name: Home }, { path: article/:id, component: ArticleDetailView, name: ArticleDetail }, { path: category/:name, component: CategoryView, name: Category }, // ... 其他前台路由 ] }, { path: /admin, component: AdminLayout, // 后台管理布局 meta: { requiresAuth: true, requiresAdmin: true }, // 路由元信息用于权限控制 children: [ { path: dashboard, component: AdminDashboard, name: AdminDashboard }, { path: article/list, component: ArticleList, name: AdminArticleList }, { path: article/edit, component: ArticleEdit, name: AdminArticleEdit }, // ... 其他后台路由 ] }, { path: /login, component: LoginView, name: Login } ]权限控制的逻辑在路由守卫中实现。在全局前置守卫router.beforeEach中检查目标路由的meta信息。如果requiresAuth为true则校验用户Token是否有效且未过期如果requiresAdmin为true还需进一步校验用户角色是否为管理员。校验失败则重定向到登录页或首页。3.3 关键页面组件与状态管理首页与文章列表首页的核心是文章列表的展示与分页。我会在HomeView组件中使用usePagination这个自定义组合式函数来管理分页状态当前页、每页条数、总数和加载状态。列表数据通过调用api/article.ts中的getArticleList方法获取。分页组件会触发页码变化事件从而重新获取数据。文章详情页这是最复杂的页面之一。它需要根据路由参数id调用API获取文章详情标题、内容、作者、时间、分类标签等。渲染Markdown内容。这里我推荐使用marked或vueuse/integrations中的useMarkdown将后端传来的Markdown字符串转换为HTML。同时为了代码高亮需要集成highlight.js。处理文章阅读量。可以在组件挂载后发送一个POST /api/article/{id}/view的请求来递增阅读数但这个接口需要做防刷处理比如同一IP短时间内只算一次。集成评论组件。评论组件本身可以是一个独立的ArticleComment.vue它接收文章ID作为prop内部管理评论的加载、发表和回复逻辑通过调用comment-service的API与后端交互。后台文章编辑页这是另一个核心组件。我强烈建议使用专业的Markdown编辑器组件如toast-ui/vue-editorToast UI Editor或md-editor-v3。它们提供所见即所得和纯Markdown编辑双模式并支持图片上传、目录生成等丰富功能。编辑器的内容Markdown格式与文章的标题、摘要、分类、标签等表单字段一起在保存时提交给后端article-service。在状态管理上如前所述我使用Pinia创建了一个userStore用于管理登录状态、Token和用户基本信息。登录成功后将用户信息和Token存入store并持久化到localStorage。其他组件通过const store useUserStore()来获取用户状态或调用store中的logout动作。4. 后端Spring Cloud微服务核心实现后端是整个系统的大脑和骨架微服务架构的复杂性主要集中在这里。我们以文章服务和网关为例深入关键实现。4.1 服务骨架搭建与通用配置每个业务服务如article-service都是一个独立的Spring Boot应用。使用Spring Initializr创建时除了选择Web、MyBatis-Plus或JPA、MySQL Driver等基础依赖外还必须引入Spring Cloud Alibaba的相关组件!-- Nacos 服务发现 -- dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency !-- Nacos 配置管理 -- dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency !-- OpenFeign -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-openfeign/artifactId /dependency在bootstrap.yml注意不是application.yml中配置Nacos Server的地址和应用名spring: application: name: article-service # 服务名用于注册 cloud: nacos: discovery: server-addr: 192.168.1.100:8848 # Nacos Server地址 config: server-addr: ${spring.cloud.nacos.discovery.server-addr} file-extension: yaml # 配置格式 group: DEFAULT_GROUP namespace: public # 命名空间可用于环境隔离这样服务启动时就会自动注册到Nacos并从Nacos读取外部化配置。4.2 业务逻辑实现以文章服务为例文章服务的核心是文章的CRUD和查询。我们设计Article实体类对应数据库表。使用MyBatis-Plus可以极大简化单表操作。1. 接口与分层采用经典的Controller-Service-Mapper三层架构。ArticleController定义RESTful API端点如GET /articles分页列表GET /articles/{id}详情POST /articles创建PUT /articles/{id}更新DELETE /articles/{id}删除。Controller层只负责参数校验、请求响应格式转换不包含业务逻辑。ArticleService及其实现类ArticleServiceImpl这里是业务逻辑的核心。例如在创建文章时除了插入文章表可能还需要更新“分类-文章”关联表、“标签-文章”关联表。这里涉及到事务管理需要在方法上添加Transactional注解。ArticleMapper由MyBatis-Plus的BaseMapper扩展而来定义数据访问方法。2. 分页查询优化文章列表分页是高频操作。MyBatis-Plus提供了强大的分页插件。在配置类中启用分页插件后在Service中可以这样写Override public PageResultArticleVO getArticlePage(ArticlePageQuery query) { // 构建分页参数和查询条件 PageArticle page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperArticle wrapper new LambdaQueryWrapper(); wrapper.eq(query.getCategoryId() ! null, Article::getCategoryId, query.getCategoryId()) .like(StringUtils.hasText(query.getKeyword()), Article::getTitle, query.getKeyword()) .orderByDesc(Article::getCreateTime); // 按发布时间倒序 // 执行分页查询 PageArticle articlePage articleMapper.selectPage(page, wrapper); // 将PageArticle 转换为 PageResultArticleVO并可能补充作者名等信息需调用user-service return convertToPageResult(articlePage); }这里有一个关键点ArticleVOView Object是返回给前端的视图对象它可能包含Article实体以外的字段比如“作者名”。而Article实体只保存作者ID。这就涉及到服务间调用。3. 服务间调用与Feign实践为了在文章列表里显示作者名article-service需要调用user-service的接口根据作者ID批量获取用户信息。我们在article-service中创建一个Feign客户端FeignClient(name user-service, path /api/users) // name对应user-service在Nacos中的服务名 public interface UserFeignClient { GetMapping(/batch) ResultListUserSimpleVO getUsersByIds(RequestParam(ids) ListLong ids); }然后在ArticleServiceImpl中注入这个UserFeignClient在convertToPageResult方法里收集所有文章的作者ID通过Feign客户端批量查询再将结果映射到ArticleVO中。这里必须考虑熔断降级如果user-service不可用不能导致文章列表完全失败。我们可以使用Spring Cloud CircuitBreaker如Resilience4j或Feign自带的fallback来提供一个默认值如显示“未知作者”。4.3 统一网关与安全控制Spring Cloud Gateway是所有流量的入口。它的主要配置在application.yml中spring: cloud: gateway: routes: - id: user-service-route uri: lb://user-service # lb:// 表示负载均衡到user-service predicates: - Path/api/users/** filters: - StripPrefix1 # 去掉路径前缀/api转发给服务的是/users/... - id: article-service-route uri: lb://article-service predicates: - Path/api/articles/** filters: - StripPrefix1 - id: auth-route uri: lb://user-service # 登录认证也转发到user-service predicates: - Path/api/auth/login filters: - StripPrefix1 globalcors: # 全局跨域配置 cors-configurations: [/**]: allowed-origins: http://localhost:5173 # 前端开发地址 allowed-methods: * allowed-headers: * allow-credentials: true权限校验是网关的核心功能之一。我们可以编写一个全局的GlobalAuthFilter实现GlobalFilter接口。在filter方法中检查请求路径是否为白名单如/api/auth/login/api/articles/public/**如果是则直接放行。对于需要认证的请求从请求头Authorization中提取JWT Token。使用JWT解析库如jjwt验证Token的签名和有效期。验证失败返回401状态码。可选将解析出的用户信息如userId放入请求头如X-User-Id传递给下游服务下游服务可以直接使用无需重复解析。实操心得网关的过滤器顺序很重要。例如认证过滤器AuthFilter应该在StripPrefix过滤器之后执行否则路径匹配可能出错。可以通过Order注解或实现Ordered接口来控制顺序。另外生产环境一定要将跨域配置的allowed-origins改为确切的前端生产域名而不是*。5. 数据存储、搜索与性能优化一个博客系统数据是根本。如何设计表结构、选择存储方案、优化查询速度直接决定了系统的稳定性和用户体验。5.1 数据库设计与核心表结构我们使用MySQL作为核心业务数据库。以下是几个核心表的设计思路用户表 (user)id,username,password加密存储,nickname,avatar,email,status,create_time等。文章表 (article)id,title,summary,contentMarkdown格式全文,html_content渲染后的HTML用于直接展示空间换时间,cover_image,author_id,category_id,status草稿/发布,view_count,like_count,create_time,update_time。关键设计将渲染后的html_content单独存储。这样前端请求文章详情时可以直接返回HTML无需在每次请求时都进行Markdown渲染极大减轻服务器压力提升响应速度。分类表 (category)与标签表 (tag)多对多关系。通过article_tag关联表来建立文章与标签的关系。评论表 (comment)id,article_id,user_id,parent_id用于回复实现嵌套评论,content,create_time。需要建立对article_id和parent_id的索引以优化查询。索引策略在article表的author_id,category_id,status,create_time上建立复合索引可以高效支持“查询某个作者发布的文章”、“按分类筛选最新文章”等场景。comment表的article_id索引对于加载文章评论列表至关重要。5.2 引入缓存与性能提升数据库是持久化存储但频繁的重复查询会给数据库带来巨大压力。引入Redis作为缓存层是必选项。1. 文章详情缓存这是收益最明显的场景。当用户请求一篇已发布的文章时流程如下public ArticleVO getArticleDetail(Long id) { String cacheKey article:detail: id; // 1. 先查缓存 ArticleVO cachedArticle redisTemplate.opsForValue().get(cacheKey); if (cachedArticle ! null) { return cachedArticle; } // 2. 缓存未命中查数据库 Article article articleMapper.selectById(id); if (article null || !ArticleStatus.PUBLISHED.equals(article.getStatus())) { throw new BusinessException(文章不存在或未发布); } // 3. 转换为VO并可能调用其他服务补全信息 ArticleVO articleVO convertToVO(article); // 4. 写入缓存设置过期时间如30分钟 redisTemplate.opsForValue().set(cacheKey, articleVO, 30, TimeUnit.MINUTES); return articleVO; }注意缓存更新当文章被修改或删除时必须主动删除或更新对应的缓存否则用户会看到旧数据。这可以通过在更新/删除文章的方法中添加删除缓存的操作来实现。2. 热点文章列表缓存首页或热门文章列表也可以缓存。但要注意列表缓存比单条缓存更复杂因为列表的查询条件分页、筛选组合很多。一种常见的策略是只缓存第一页数据或者缓存“最新文章”这类固定查询的结果。3. 分布式Session在微服务架构下用户的Session信息如登录状态不能存在单个服务的本地内存中。我们可以将Spring Session的存储后端配置为Redis这样所有服务都能共享和识别同一个Session。5.3 全文检索与文件存储方案全文检索初期对于小规模博客使用MySQL的LIKE或FULLTEXT索引可能够用。但当文章数量上千、对搜索速度和相关性排序有要求时必须引入专业的搜索引擎。Elasticsearch (ES)是首选。我们可以搭建一个search-service在文章发布或更新时通过消息队列如RabbitMQ异步地将文章数据同步到ES中。前端搜索请求发送到网关网关路由到search-service由该服务向ES发起查询并返回结果。这种设计解耦了写操作发布文章和读操作搜索保证了搜索的性能和可用性。文件存储独立的file-service负责处理所有文件上传。前端通过input typefile或拖拽上传图片将文件以multipart/form-data格式发送到file-service的/upload接口。该接口需要校验文件类型只允许图片和大小。生成一个唯一的文件名如UUID 后缀防止覆盖。将文件保存到指定位置。生产环境强烈建议使用对象存储如阿里云OSS、腾讯云COS。它们提供高可用、高扩展、低成本的文件存储服务并且自带CDN加速。file-service只需调用OSS的SDK上传文件并将返回的文件访问URL存入数据库或返回给前端。前端拿到URL后将其插入到Markdown编辑器的光标位置形成的格式。6. 部署、监控与常见问题排查系统开发完成如何让它稳定、可靠地跑起来是另一个重要的课题。6.1 多环境部署与CI/CD我们需要至少三个环境开发dev、测试test、生产prod。不同环境的配置数据库地址、Redis地址、OSS密钥等通过Nacos配置中心进行管理。在Nacos中为每个环境创建不同的namespace服务启动时通过指定spring.cloud.nacos.config.namespace来加载对应环境的配置。使用Docker进行容器化部署是微服务的标准做法。为每个服务编写Dockerfile将编译好的Jar包和运行环境打包成镜像。然后使用docker-compose.yml来定义所有服务包括Nacos、MySQL、Redis的依赖关系和启动顺序。在生产环境通常会使用Kubernetes进行容器编排。CI/CD流程可以借助GitLab CI/CD或Jenkins实现。基本的流水线包括代码拉取 - 单元测试 - 编译打包 - 构建Docker镜像 - 推送镜像到私有仓库 - 更新Kubernetes部署。自动化部署能极大减少人为错误提高发布效率。6.2 基础监控与日志追踪“可观测性”是微服务的生命线。我们需要知道服务是否健康、性能如何、出错在哪里。健康检查Spring Boot Actuator提供了/actuator/health端点可以集成到Nacos中作为健康检查的路径。Nacos会定期调用此端点如果服务不健康则将其从服务实例列表中剔除避免网关将请求路由到故障实例。日志聚合每个服务都将日志输出到标准输出stdout。然后通过ELKElasticsearch, Logstash, Kibana或EFKFluentd替代Logstash栈来收集、解析、存储和展示所有容器的日志。在Kubernetes中可以部署一个Fluentd作为DaemonSet来收集每个节点的日志。这样当出现问题时我们可以在一个统一的界面中根据时间、服务名、TraceId等关键词快速检索到相关的所有日志。链路追踪对于一次前端的文章列表请求它可能经过Gateway - Article-Service同时Feign调用了User-Service。我们需要追踪这个请求的完整路径和耗时。可以使用SkyWalking或Zipkin。在服务中集成对应的客户端agent它会自动为每个请求生成一个唯一的TraceId并记录经过的每个服务节点Span的信息。通过可视化界面我们能清晰地看到一次调用的链路、每个环节的耗时快速定位性能瓶颈或错误源头。6.3 典型问题排查实录在开发和运维这个博客系统的过程中我踩过不少坑这里分享几个典型问题及其解决思路。问题一服务间调用超时FeignException$ReadTimeout现象article-service调用user-service获取作者信息时偶尔超时失败导致文章列表作者名显示为空或报错。排查检查user-service的监控发现其CPU和内存正常但某个时间段接口响应时间变长。查看user-service日志发现该时间段有慢SQL查询。检查数据库发现用户表缺少必要索引当执行联表查询或复杂条件查询时性能低下。解决为user-service中响应慢的查询语句涉及的字段添加索引。同时在article-service的Feign客户端配置中适当调整超时时间connectTimeout,readTimeout并启用熔断器如Resilience4j设置降级策略返回默认用户信息。问题二Gateway路由404现象前端请求/api/articles返回404但直接调用article-service的IP端口是通的。排查检查Gateway的路由配置确认Path/api/articles/**的路由规则存在且指向lb://article-service。检查Nacos控制台确认article-service有健康的实例在线。查看Gateway的访问日志发现请求确实被接收了。问题可能出在StripPrefix过滤器。解决检查发现article-service本身配置的上下文路径server.servlet.context-path是/而Gateway的过滤器配置了StripPrefix1去掉了/api前缀转发过去的是/articles。但article-service的Controller映射路径是/api/articles。这里出现了不匹配。解决方案要么修改Gateway的StripPrefix为2如果路径是/api/article-service/api/articles这种模式更常见的做法是统一规范所有业务服务的接口都以/api开头Gateway配置StripPrefix1这样转发过去的就是服务期望的路径。问题三前端部署后访问API出现CORS错误现象本地开发联调正常将前端静态文件部署到Nginx后访问后端API时报错“Access-Control-Allow-Origin”。排查这是经典的跨域问题。本地开发时Vite的代理服务器帮忙处理了跨域。生产环境Nginx不会自动添加CORS头。解决有两种方案。方案一推荐在Nginx配置中为前端域名添加CORS响应头。方案二确保生产环境前后端部署在同一个域名下通过Nginx location区分这样就变成了同源请求不存在跨域问题。例如Nginx配置中/指向前端静态文件/api/反向代理到后端Gateway。问题四图片上传后前端Markdown编辑器无法显示现象在后台编辑文章上传图片成功返回了URL但插入编辑器后不显示。排查检查浏览器开发者工具的Network面板查看图片URL的请求是否发出返回状态码是什么。如果返回403或404说明图片URL不对或资源不可访问。检查file-service返回的URL是否正确以及文件是否成功上传到了OSS或指定目录。检查OSS的Bucket权限是否设置为公共读对于博客图片通常是需要的或者Nginx是否配置了正确的静态资源目录权限。解决确保file-service返回的URL是完整的、可公开访问的地址。如果使用本地存储需要配置Nginx将某个路径如/uploads/映射到服务器的文件目录并设置正确的权限。构建一个完整的VueSpringCloud博客系统是一次从前端到后端、从单体到分布式、从开发到运维的全面演练。每一个环节的深入思考和细节处理都让这个项目远超一个简单的“毕业设计”。它更像一个微缩的企业级应用涵盖了现代Web开发中大多数核心概念和最佳实践。希望这份详细的拆解和实录能为你自己的项目实践提供扎实的参考。记住架构没有银弹最适合的才是最好的。在满足当前需求的前提下选择你熟悉且能hold住的技术栈逐步迭代才是工程实践的真正智慧。本文还有配套的精品资源点击获取