企业门户网站这类项目在JavaWeb领域里算是既常见又容易做“飘”的一种。说常见是因为几乎每个做Java开发的人职业生涯里都绕不过企业官网、集团门户、政府信息公开平台这类信息展示类系统说容易做“飘”是因为很多人把它当“增删改查”的堆砌做完能跑就行结果页面打开慢、后台不好维护、加个新栏目要改一大片代码最后把自己坑进去。这篇博客我想结合一个实际落地的“javaweb企业多模块系统——企业门户网站”项目聊聊这类系统从设计到实现到底该怎么思考。核心关键词就两个javaweb和多模块系统。适合正在做毕设、课设或者刚入职需要独立支撑一个中小型企业官网项目的同学参考。看完你能少走不少弯路。我最初接手这个项目时需求方只给了三句话做一个企业官网前台展示公司信息后台能发布新闻和产品。听起来很简单对吧但真做起来你会发现如果前期不把模块边界划清楚后面每加一个功能都会牵动全身。这篇文章的主角是一个基于Maven多模块架构的JavaWeb门户系统前后端分离与后端模板渲染相结合覆盖企业官网最常见的新闻动态、产品展示、招聘信息、留言反馈、后台权限管理等场景。它不是那种炫技的项目但足够典型几乎所有做JavaWeb的开发者都能从中找到自己项目的影子。1. 项目到底在解决什么问题——企业门户系统的本质需求1.1 企业门户网站的真实业务场景先别急着写代码搞清楚企业门户网站到底是给谁用的比选什么框架重要得多。我见过太多开发者的第一反应是“官网嘛就是几个页面加个后台”然后把大量精力花在花哨的首页动画上结果真正核心的内容管理功能反而做得稀烂。企业门户网站的用户分三类访问者、内容维护者、系统管理员。访问者要的是快速找到企业信息包括公司介绍、产品服务、新闻动态、联系方式这些基础内容内容维护者通常是市场部或行政部的人他们不懂代码需要一个能打字、能传图、能一键发布的后台系统管理员的诉求则是账号管理、栏目调整、数据备份这些运维能力。这三类需求叠加在一起其实就引出了一个关键结论企业门户系统本质上是一个内容管理系统CMS只不过它的前台展示比通用CMS更强调企业品牌调性。所以项目架构必须把“内容管理”这个核心能力做扎实而不是把时间花在写那些一次性的展示页面上。理解了这一点你才知道为什么要做后台栏目管理、内容发布、图片上传、权限控制也才会理解多模块拆分在这类项目里不是过度设计而是真实需要。1.2 为什么JavaWeb需要多模块架构很多初学者甚至工作两三年的同学拿到项目就是新建一个Spring Boot工程所有代码堆在一个模块里。如果只是几十张表的内部管理系统这样干问题不大。但企业门户这类项目前台展示和后台管理天然就是两套逻辑加上公共的工具类、统一的返回结果封装、数据库访问层如果全放在一个工程里代码会迅速变得不可维护。我举个例子前台门户需要根据栏目类型展示不同的内容模板后台管理需要校验权限、记录操作日志这两块业务几乎没有交集唯一的共同点是都要访问数据库、都要用同一个工具类。放在同一个包下后果就是前台代码里到处是后台的权限注解后台的代码里混着前台的页面渲染逻辑。改一个bug牵连一片谁都不敢动代码。多模块系统解决的就是这个痛点。Maven把项目拆分成可以独立编译、独立测试的多个模块模块之间通过依赖建立关系。我在这个门户项目里采用了经典的四模块结构父工程统一管理依赖版本common模块放工具类和通用返回结果system模块处理后台管理与权限web模块负责前台展示。这样一个清晰的边界让每个模块各司其职也让后续扩展新功能变得非常从容——想加一个会员系统新建一个member模块依赖system模块的权限能力不动其它任何代码。2. 技术选型与整体架构设计2.1 技术栈选择的取舍逻辑企业门户用什么技术栈其实没有标准答案关键看你所在团队的技术积累和项目维护周期。我做这个项目时选用的是一套非常“稳”的组合JDK 8 Maven 3.6 Spring Boot 2.7 MyBatis-Plus MySQL 5.7。前端没有走前后端分离而是用了Thymeleaf模板引擎加Layui后台模板。这套组合的好处是学习成本低、生态成熟、网上资料多遇到问题随便一搜就有答案。为什么不用前后端分离我得说实话。企业门户这类项目内容展示型页面居多搜索引擎优化SEO天然对服务端渲染更友好。前后端分离听起来时髦但你要考虑它带来的额外复杂度比如跨域配置、鉴权方案、前端工程构建环境等。对一个需要快速交付、持续迭代的官网项目来说服务端模板渲染是更实际的方案。当然如果你做的是面向特定用户群体的应用系统前后端分离会更好但做官网别被技术时髦绑架了。2.2 多模块工程的拆分策略多模块拆分并没有统一标准但它有一个非常重要的原则按业务边界拆不按代码层次拆。很多人把工程拆成controller模块、service模块、dao模块这是典型的错误做法。按层次拆会让模块之间循环依赖比如dao模块不该依赖service模块但业务逻辑又确实调了dao拆到最后变成一团乱麻。我的做法是按业务域拆分common模块零业务逻辑放工具类、统一异常、统一返回结果、常量定义。好理解就是每个模块都需要的基础设施。system模块承载后台管理所有业务包括管理员登录、权限控制、栏目管理、内容发布、产品管理、数据统计。它依赖common模块。web模块承载前台门户所有功能包括首页数据展示、新闻列表与详情、产品列表、留言提交、招聘信息展示。它同时依赖common和system两个模块因为前台要复用system模块里对栏目和内容的查询能力。这套拆分方案的好处是依赖关系清晰自上而下单向依赖不会出现循环引用。编译和打包层面也更灵活比如更新了system模块只需单独重新部署system模块对应的服务不必把整个工程重新打包。如果你做成的是一个多模块的单体应用那至少代码组织上也有了清晰的边界。2.3 项目内部包结构与职责划分模块分完了每个模块内部的包结构同样要讲究。我在web模块内部的包结构是这样的controller只做参数接收和结果返回不写任何业务逻辑service定义接口承载业务规则service.impl业务实现mapperMyBatis的Mapper接口entity数据库实体类vo视图层对象专门用来封装页面上需要的数据结构一个小细节很多初学者不注意实体类和前端页面需要的数据往往不是一回事。比如后端管理编辑新闻时需要一个表单对象来承接编辑器提交的富文本内容但前台展示新闻列表时前端只需要标题、发布时间、封面图不需要正文全文。如果全程用同一个实体类要么前端会拿到一堆用不上的字段要么后端要为每个场景单独写查询方法。我用VO对象做了一层隔离避免实体类被页面数据“绑架”这个习惯在项目后期帮了大忙。3. 数据库设计先想清楚业务再动代码3.1 核心业务模块与数据表规划企业门户网站的数据表我规划了九张核心表。这不是拍脑袋决定的完全是根据业务模块推导出来的。门户前台需要展示企业信息对应的是企业简介、资质荣誉这些内容它们可以统一归入“文章”体系由一张article表承载产品模块需要产品表product和产品分类表product_category招聘模块需要职位表job用户留言需要message表后台管理需要管理员表admin_user、角色表role、菜单表menu以及管理员与角色的关联表。这里有一个我很想强调的设计思想栏目和内容分离。很多企业门户系统喜欢把新闻和公告各建一张表甚至把“公司简介”这种单页内容单独建一个表每加一个栏目就建一张表最后数据库里二十多张结构类似的表维护起来简直是灾难。我采用了栏目动态化的思路用一张category表维护所有栏目通过一个type字段区分栏目类型内容统一存在article表里article关联category的id。这样的设计让新增栏目变成后台的数据操作而不是一次代码开发和数据库变更对运营来说极其友好。3.2 核心表结构设计与字段说明文章表是整个系统的内容中枢我重点说一下它的设计要点。表字段包括id、category_id、title、summary、cover_image、content、author、source、is_top、status、create_time、update_time。其中status字段只有两个值1表示已发布0表示草稿这个字段虽然简单却是内容发布流程里的核心控制点。is_top用来控制置顶很多官网首页会有“重点新闻”区域这个字段就是为它准备的。产品表需要特别考虑分类与图片。分类用product_category表字段包括id、parent_id、name、sort。parent_id的设计让产品分类支持两级结构比如“工业设备→包装设备”在实际企业门户里这个场景非常常见。产品表本身有product_name、sub_title、main_image、images、product_desc这些字段其中images我用了JSON字符串格式存储点击查看大图的轮播列表。这里分享一个经验企业官网的产品展示首图是否精美直接决定页面观感所以产品表必须在创建时就把首图的处理逻辑设计好比如上传时自动生成缩略图而不是原图直接展示。3.3 字段设计的几个实用原则数据库字段设计看似简单实际踩坑的不少。第一个原则是预留扩展位但不滥用。我在文章表里预留了一个remark字段后来需求方要在新闻列表加一个“来源链接”的跳转时这个字段直接派上了用场。但切不要预留下一堆用不上的冗余字段那只会让代码变臃肿。第二个原则是时间字段统一用datetime类型不要用timestamp。两者虽然功能接近但timestamp有2038年问题而且受时区影响在项目里出现过凌晨时间显示差8小时的情况。统一用datetime加默认值CURRENT_TIMESTAMP省心。第三个原则是外键不要加到数据库层面。这句话说出来很多学院派的同学可能不认可但这种面向中小型门户的项目网络开销和死锁风险都要考虑外键约束放到应用层去保证完全够用。数据库表之间能通过字段语义建立关联查询靠SQL的JOIN就够了这样也方便后期做分库分表或数据迁移。4. 功能模块的落地实现从搭建工程到核心功能4.1 三种方式快速创建一个多模块工程多模块工程的第一步是搭一个标准的Maven父工程。我用的是IDEA有两种常见方式。一种是在IDEA里新建Project选择Spring Initializr生成一个父工程后删除src目录把pom.xml的packaging改为pom然后逐个添加module。另一种更推荐的做法是只建一个空的Maven工程手动在pom.xml里声明所有模块名称再通过IDEA的模块创建功能补齐代码目录。父工程的pom.xml核心配置大致是这样groupIdcom.example/groupId artifactIdportal-parent/artifactId version1.0.0/version packagingpom/packaging modules moduleportal-common/module moduleportal-system/module moduleportal-web/module /modules dependencyManagement dependencies !-- 统一管理Spring Boot版本和内部模块版本 -- /dependencies /dependencyManagement这里有一个很关键的细节父工程里只做依赖版本管理不要直接引用任何依赖。子模块需要什么依赖自己声明版本号由父工程统一控制。这样避免了“子模块A升级依赖导致子模块B出问题”的情况。模块建好之后最让人头疼的问题就是模块之间的依赖方向。我的约定是web模块依赖system模块system模块依赖common模块common模块不依赖其它内部模块。如果你的系统里发现出现了common依赖web的情况那说明代码放错了位置先重构再写功能。4.2 前台门户内容展示的三个关键功能实现前台门户看着简单实际实现上有几个功能非常考验细心程度。第一个是首页数据的聚合查询。首页通常要同时展示轮播图、最新新闻、推荐产品、企业公告这几个区域如果分别调接口、分别返回数据前端就要发多次请求页面加载会明显变慢。我用了异步初始化缓存思维在service层提供一个聚合查询方法一次查出所有首页区块所需数据封装成一个Map或一个IndexVO返回给前端。后期加了Redis缓存首页的响应时间稳定在20毫秒以内。第二个是通用的内容列表分页。前台新闻列表、产品列表、招聘列表都需要分页。我封装了一个PageResult对象统一接收当前页码、每页数量、总记录数、当前页数据这四个信息。MyBatis-Plus自带分页插件配置一个拦截器即可Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这里一个小坑分页插件必须配置在MyBatis-Plus的拦截器链中如果你的项目里同时用了其它MyBatis拦截器要注意顺序否则分页SQL可能不生效。我早期做过一个项目自定义拦截器和分页拦截器顺序不对导致分页总数一直为0排查了整整一天。第三个是留言功能的前后端校验。企业门户的留言表单最怕的是垃圾信息。我在前端做了必填项和手机号格式校验后端再用Hibernate Validator做一次同样的校验这样能挡住直接绕过前端用接口调用的请求。留言表设计时特意加了status字段默认状态是待审核后台审核通过才在前台展示。这一点即使需求方没有提我也坚持做了后来果然派上了用场——留言功能上线第二周就收到好几条广告留言全部被审核机制拦住了。4.3 后台管理权限控制与内容管理的核心实现后台管理是企业门户系统的操盘中心除了栏目和内容的增删改查权限控制是我不愿意妥协的一块。一个支持多角色的后台核心是三个东西身份认证、权限拦截、菜单动态生成。身份认证我用Spring Security实现自定义了一个UserDetailsService从admin_user表里查出用户信息校验密码后生成一个JWT令牌返回给前端。这里坦白讲用Spring Security做表单登录和接口鉴权配置量比Shiro大但它对多角色的支持更原生尤其是方法级别的权限控制一个PreAuthorize(hasRole(ADMIN))注解就能搞定。权限拦截不只是拦住非法的请求还承担了一个重要职责菜单动态展示。我设计了一套基于RBAC模型的权限体系管理员登录后根据角色查询能访问的菜单前台只渲染这些菜单项。这样市场部的人登录后台看不到系统管理的入口管理员登录能看到全部菜单。这套逻辑不复杂却是很多“毕设级”项目最缺失的部分不少门户后台是所有人都能直接进系统管理页面这在真实企业场景里是绝对不能接受的。内容管理模块里富文本编辑器和图片上传是两大核心。富文本我用的是UEditor因为它是国内用得最多、文档最全的编辑器虽然官方维护不积极了但成熟稳定。图片上传做了一个统一接口设计了按日期分目录存储比如/uploads/2025/06/15/时间戳.jpg这样管理图片时按时间维度非常方便。上传后返回图片URL富文本编辑器直接把URL插入内容即可。图片上传这里有个极其常见的问题就是文件存储路径和访问路径不一致。我见过很多新手图片存到了本地磁盘的某个目录前端页面却用项目的静态资源路径去访问结果404。我的做法是上传接口返回的URL使用可配置的全局前缀比如/upload/**在Spring Boot里配置一个资源映射把这个路径映射到实际存储目录。Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }这个配置解决了本地开发的路径映射但要注意部署到服务器后uploadPath如果写在配置文件的相对路径里可能会因为启动目录不同而找不到图片。最稳妥的方式是在配置文件中配置一个绝对路径比如Linux下的/opt/data/portal/upload/Windows下的D:/portal/upload/启动时打印给运维人员确认。5. 实战中遇到的高频问题和解决办法5.1 静态资源404与拦截器冲突前台页面加载不出CSS和JS是最典型的JavaWeb问题。排查思路很简单第一件事就是看请求的URL确认是不是静态资源路径被拦截了。我在这里栽过跟头曾经在Spring Security的拦截规则里把所有非登录接口都拦下来忘了放行静态资源导致登录页面的CSS全部404。解决方式是配置白名单把静态资源路径、登录接口、上传文件访问路径都放行.antMatchers(/css/**, /js/**, /images/**, /upload/**, /login, /portal/**).permitAll()还有一个隐藏很深的坑如果项目里同时使用了Spring MVC的拦截器和Spring Security那么静态资源的放行必须在两边都配置。只配了Security不配MVC拦截器同样会被拦住。我第一次排查这个问题时一度怀疑是资源路径写错了折腾半天才发现是两套拦截机制叠加导致。5.2 中文乱码问题中文乱码在企业门户项目里几乎是必现的因为前后台都要处理新闻标题、产品名称这些中文内容。乱码的根因无非三类数据库编码不对、请求编码不对、响应编码不对。数据库层面建库时就要明确用utf8mb4字符集连接参数里加上characterEncodingutf8useUnicodetrue。这里特别说一下utf8mb4和utf8的区别utf8在MySQL里最多支持3字节的字符像一些生僻字和emoji是存不进去的用utf8mb4才是完整覆盖Unicode的字符集。请求和响应编码Spring Boot里最简单的方式是配置一个CharacterEncodingFilter强制使用UTF-8。但注意这个过滤器要放在最前面执行如果被业务拦截器抢先处理了请求后面再设置编码就来不及了。我见过不少人的乱码问题其实是配置顺序搞错了。5.3 上传功能的各种坑上传图片不成功、上传大图超时是后台管理功能里被吐槽最多的问题。Spring Boot默认的单文件上传大小限制是1MB企业门户后台要经常上传产品大图动辄2~3MB直接就被拦住了。在配置里调大限制spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB这里有个细节max-file-size是单个文件的最大值max-request-size是一次请求中多个文件的总大小。只调前者不调后者前端连传三张大图时照样报错。还有个问题容易被忽略就是上传图片的格式校验。不要只靠前端限制文件类型因为接口可以被绕过。后端一定要做校验包括扩展名白名单比如只允许jpg、png、gif、webp以及文件真实内容校验判断文件头魔数。5.4 多模块协作中的依赖陷阱多模块工程跑起来之后最常见的报错就是ClassNotFoundException和NoSuchMethodError。ClassNotFoundException通常是模块之间没有正确添加依赖打开IDEA的Project Structure确认一下依赖关系就能发现。NoSuchMethodError则更隐蔽多半是jar包冲突两个模块依赖了同一个库的不同版本。解决思路是统一版本号这就是父工程里dependencyManagement存在的意义子模块不要自己指定不必要的版本号一切交给父工程管理。还有一个非常容易踩的坑是改了common模块里的工具类但依赖common的system模块没有重新构建导致运行时用的还是旧代码。Maven多模块开发时每次改完子模块代码务必要对依赖它的模块也执行一次install或者直接对整个工程执行clean install。这件事看起来不起眼但在多人协作时经常导致“我明明改了代码运行结果没变化”的尴尬局面。5.5 门户前台访问速度慢企业门户对访问速度的要求是天然的一个首页加载5秒的官网不管是客户还是老板都接受不了。我做的性能优化主要分三层。第一层是数据库优化列表页都加了必要的索引比如article表的status、create_time字段以及product表的product_category_id字段。查询时尽量用MyBatis-Plus的LambdaQueryWrapper避免手写拼接SQL导致的注入风险。第二层是缓存优化首页的数据查询结果缓存到Redis缓存时间设为5分钟并提供一个后台“一键刷新缓存”的按钮。管理员在后台改了新闻或产品点击按钮或者设置定时任务让缓存自动失效。这个设计让页面响应速度和运营实时性做到了兼顾。第三层是静态资源配置Nginx上加了对静态资源文件的expires设定让浏览器强缓存图片、CSS和JS文件。这个优化效果最明显几乎把静态资源请求的量级直接砍掉了绝大部分。6. 项目完成后我的一些实际操作体会这个企业门户多模块系统做下来我最深的体会是JavaWeb项目最考验人的往往不是某个框架有多熟而是对整个系统边界的理解。多模块的拆分不是给简历上多写一行“熟练使用Maven多模块”而是一种真正让代码更好维护、更好协作的组织方式。有两点实操经验我想单独拿出来说。第一点多模块工程里的模块命名一定要有极强的一致性。我见过有人用portal、core、manager三种风格来命名模块结果半年后自己都分不清哪些代码放在哪个模块。我在这个项目里统一用portal-前缀然后按职责分portal-common、portal-system、portal-web并且把main函数放在portal-web模块父工程和common模块都不包含启动类。第二点后台表格列的展示需求一定要提前跟运营确认。企业门户后台的内容列表看起来是简单的表格但不同的运营人员对字段的诉求差异很大。有的要看发布人有的只看发布时间有的要在列表里直接看到封面图。如果前期不确认好后期改表格列的频率会非常高而每次都涉及前端表格渲染和后端实体类返回改起来很痛苦。我的做法是列表查询接口直接返回一个专门的ListVO把可能需要的字段都包含进去宁可前端渲染时不用也不要在后期反复改接口。如果你也是正在做JavaWeb企业门户或者在准备相关项目的设计希望这篇内容能帮你避开我踩过的坑。这个系统后续如果要扩展我个人觉得比较有价值的方向是接入单点登录给企业内部的多个子系统提供统一的身份认证以及把前台门户的首页数据用更成熟的内容分发策略做优化实现真正的动态化运营。这些在现有架构下都能稳妥地扩展毕竟模块边界已经留好了位置。 
长河君 · 2026/9/9 16:13:06 · 阅读 1.2k JavaWeb企业门户网站多模块系统设计与实战：从架构到落地
企业门户网站这类项目在JavaWeb领域里算是既常见又容易做“飘”的一种。说常见是因为几乎每个做Java开发的人职业生涯里都绕不过企业官网、集团门户、政府信息公开平台这类信息展示类系统说容易做“飘”是因为很多人把它当“增删改查”的堆砌做完能跑就行结果页面打开慢、后台不好维护、加个新栏目要改一大片代码最后把自己坑进去。这篇博客我想结合一个实际落地的“javaweb企业多模块系统——企业门户网站”项目聊聊这类系统从设计到实现到底该怎么思考。核心关键词就两个javaweb和多模块系统。适合正在做毕设、课设或者刚入职需要独立支撑一个中小型企业官网项目的同学参考。看完你能少走不少弯路。我最初接手这个项目时需求方只给了三句话做一个企业官网前台展示公司信息后台能发布新闻和产品。听起来很简单对吧但真做起来你会发现如果前期不把模块边界划清楚后面每加一个功能都会牵动全身。这篇文章的主角是一个基于Maven多模块架构的JavaWeb门户系统前后端分离与后端模板渲染相结合覆盖企业官网最常见的新闻动态、产品展示、招聘信息、留言反馈、后台权限管理等场景。它不是那种炫技的项目但足够典型几乎所有做JavaWeb的开发者都能从中找到自己项目的影子。1. 项目到底在解决什么问题——企业门户系统的本质需求1.1 企业门户网站的真实业务场景先别急着写代码搞清楚企业门户网站到底是给谁用的比选什么框架重要得多。我见过太多开发者的第一反应是“官网嘛就是几个页面加个后台”然后把大量精力花在花哨的首页动画上结果真正核心的内容管理功能反而做得稀烂。企业门户网站的用户分三类访问者、内容维护者、系统管理员。访问者要的是快速找到企业信息包括公司介绍、产品服务、新闻动态、联系方式这些基础内容内容维护者通常是市场部或行政部的人他们不懂代码需要一个能打字、能传图、能一键发布的后台系统管理员的诉求则是账号管理、栏目调整、数据备份这些运维能力。这三类需求叠加在一起其实就引出了一个关键结论企业门户系统本质上是一个内容管理系统CMS只不过它的前台展示比通用CMS更强调企业品牌调性。所以项目架构必须把“内容管理”这个核心能力做扎实而不是把时间花在写那些一次性的展示页面上。理解了这一点你才知道为什么要做后台栏目管理、内容发布、图片上传、权限控制也才会理解多模块拆分在这类项目里不是过度设计而是真实需要。1.2 为什么JavaWeb需要多模块架构很多初学者甚至工作两三年的同学拿到项目就是新建一个Spring Boot工程所有代码堆在一个模块里。如果只是几十张表的内部管理系统这样干问题不大。但企业门户这类项目前台展示和后台管理天然就是两套逻辑加上公共的工具类、统一的返回结果封装、数据库访问层如果全放在一个工程里代码会迅速变得不可维护。我举个例子前台门户需要根据栏目类型展示不同的内容模板后台管理需要校验权限、记录操作日志这两块业务几乎没有交集唯一的共同点是都要访问数据库、都要用同一个工具类。放在同一个包下后果就是前台代码里到处是后台的权限注解后台的代码里混着前台的页面渲染逻辑。改一个bug牵连一片谁都不敢动代码。多模块系统解决的就是这个痛点。Maven把项目拆分成可以独立编译、独立测试的多个模块模块之间通过依赖建立关系。我在这个门户项目里采用了经典的四模块结构父工程统一管理依赖版本common模块放工具类和通用返回结果system模块处理后台管理与权限web模块负责前台展示。这样一个清晰的边界让每个模块各司其职也让后续扩展新功能变得非常从容——想加一个会员系统新建一个member模块依赖system模块的权限能力不动其它任何代码。2. 技术选型与整体架构设计2.1 技术栈选择的取舍逻辑企业门户用什么技术栈其实没有标准答案关键看你所在团队的技术积累和项目维护周期。我做这个项目时选用的是一套非常“稳”的组合JDK 8 Maven 3.6 Spring Boot 2.7 MyBatis-Plus MySQL 5.7。前端没有走前后端分离而是用了Thymeleaf模板引擎加Layui后台模板。这套组合的好处是学习成本低、生态成熟、网上资料多遇到问题随便一搜就有答案。为什么不用前后端分离我得说实话。企业门户这类项目内容展示型页面居多搜索引擎优化SEO天然对服务端渲染更友好。前后端分离听起来时髦但你要考虑它带来的额外复杂度比如跨域配置、鉴权方案、前端工程构建环境等。对一个需要快速交付、持续迭代的官网项目来说服务端模板渲染是更实际的方案。当然如果你做的是面向特定用户群体的应用系统前后端分离会更好但做官网别被技术时髦绑架了。2.2 多模块工程的拆分策略多模块拆分并没有统一标准但它有一个非常重要的原则按业务边界拆不按代码层次拆。很多人把工程拆成controller模块、service模块、dao模块这是典型的错误做法。按层次拆会让模块之间循环依赖比如dao模块不该依赖service模块但业务逻辑又确实调了dao拆到最后变成一团乱麻。我的做法是按业务域拆分common模块零业务逻辑放工具类、统一异常、统一返回结果、常量定义。好理解就是每个模块都需要的基础设施。system模块承载后台管理所有业务包括管理员登录、权限控制、栏目管理、内容发布、产品管理、数据统计。它依赖common模块。web模块承载前台门户所有功能包括首页数据展示、新闻列表与详情、产品列表、留言提交、招聘信息展示。它同时依赖common和system两个模块因为前台要复用system模块里对栏目和内容的查询能力。这套拆分方案的好处是依赖关系清晰自上而下单向依赖不会出现循环引用。编译和打包层面也更灵活比如更新了system模块只需单独重新部署system模块对应的服务不必把整个工程重新打包。如果你做成的是一个多模块的单体应用那至少代码组织上也有了清晰的边界。2.3 项目内部包结构与职责划分模块分完了每个模块内部的包结构同样要讲究。我在web模块内部的包结构是这样的controller只做参数接收和结果返回不写任何业务逻辑service定义接口承载业务规则service.impl业务实现mapperMyBatis的Mapper接口entity数据库实体类vo视图层对象专门用来封装页面上需要的数据结构一个小细节很多初学者不注意实体类和前端页面需要的数据往往不是一回事。比如后端管理编辑新闻时需要一个表单对象来承接编辑器提交的富文本内容但前台展示新闻列表时前端只需要标题、发布时间、封面图不需要正文全文。如果全程用同一个实体类要么前端会拿到一堆用不上的字段要么后端要为每个场景单独写查询方法。我用VO对象做了一层隔离避免实体类被页面数据“绑架”这个习惯在项目后期帮了大忙。3. 数据库设计先想清楚业务再动代码3.1 核心业务模块与数据表规划企业门户网站的数据表我规划了九张核心表。这不是拍脑袋决定的完全是根据业务模块推导出来的。门户前台需要展示企业信息对应的是企业简介、资质荣誉这些内容它们可以统一归入“文章”体系由一张article表承载产品模块需要产品表product和产品分类表product_category招聘模块需要职位表job用户留言需要message表后台管理需要管理员表admin_user、角色表role、菜单表menu以及管理员与角色的关联表。这里有一个我很想强调的设计思想栏目和内容分离。很多企业门户系统喜欢把新闻和公告各建一张表甚至把“公司简介”这种单页内容单独建一个表每加一个栏目就建一张表最后数据库里二十多张结构类似的表维护起来简直是灾难。我采用了栏目动态化的思路用一张category表维护所有栏目通过一个type字段区分栏目类型内容统一存在article表里article关联category的id。这样的设计让新增栏目变成后台的数据操作而不是一次代码开发和数据库变更对运营来说极其友好。3.2 核心表结构设计与字段说明文章表是整个系统的内容中枢我重点说一下它的设计要点。表字段包括id、category_id、title、summary、cover_image、content、author、source、is_top、status、create_time、update_time。其中status字段只有两个值1表示已发布0表示草稿这个字段虽然简单却是内容发布流程里的核心控制点。is_top用来控制置顶很多官网首页会有“重点新闻”区域这个字段就是为它准备的。产品表需要特别考虑分类与图片。分类用product_category表字段包括id、parent_id、name、sort。parent_id的设计让产品分类支持两级结构比如“工业设备→包装设备”在实际企业门户里这个场景非常常见。产品表本身有product_name、sub_title、main_image、images、product_desc这些字段其中images我用了JSON字符串格式存储点击查看大图的轮播列表。这里分享一个经验企业官网的产品展示首图是否精美直接决定页面观感所以产品表必须在创建时就把首图的处理逻辑设计好比如上传时自动生成缩略图而不是原图直接展示。3.3 字段设计的几个实用原则数据库字段设计看似简单实际踩坑的不少。第一个原则是预留扩展位但不滥用。我在文章表里预留了一个remark字段后来需求方要在新闻列表加一个“来源链接”的跳转时这个字段直接派上了用场。但切不要预留下一堆用不上的冗余字段那只会让代码变臃肿。第二个原则是时间字段统一用datetime类型不要用timestamp。两者虽然功能接近但timestamp有2038年问题而且受时区影响在项目里出现过凌晨时间显示差8小时的情况。统一用datetime加默认值CURRENT_TIMESTAMP省心。第三个原则是外键不要加到数据库层面。这句话说出来很多学院派的同学可能不认可但这种面向中小型门户的项目网络开销和死锁风险都要考虑外键约束放到应用层去保证完全够用。数据库表之间能通过字段语义建立关联查询靠SQL的JOIN就够了这样也方便后期做分库分表或数据迁移。4. 功能模块的落地实现从搭建工程到核心功能4.1 三种方式快速创建一个多模块工程多模块工程的第一步是搭一个标准的Maven父工程。我用的是IDEA有两种常见方式。一种是在IDEA里新建Project选择Spring Initializr生成一个父工程后删除src目录把pom.xml的packaging改为pom然后逐个添加module。另一种更推荐的做法是只建一个空的Maven工程手动在pom.xml里声明所有模块名称再通过IDEA的模块创建功能补齐代码目录。父工程的pom.xml核心配置大致是这样groupIdcom.example/groupId artifactIdportal-parent/artifactId version1.0.0/version packagingpom/packaging modules moduleportal-common/module moduleportal-system/module moduleportal-web/module /modules dependencyManagement dependencies !-- 统一管理Spring Boot版本和内部模块版本 -- /dependencies /dependencyManagement这里有一个很关键的细节父工程里只做依赖版本管理不要直接引用任何依赖。子模块需要什么依赖自己声明版本号由父工程统一控制。这样避免了“子模块A升级依赖导致子模块B出问题”的情况。模块建好之后最让人头疼的问题就是模块之间的依赖方向。我的约定是web模块依赖system模块system模块依赖common模块common模块不依赖其它内部模块。如果你的系统里发现出现了common依赖web的情况那说明代码放错了位置先重构再写功能。4.2 前台门户内容展示的三个关键功能实现前台门户看着简单实际实现上有几个功能非常考验细心程度。第一个是首页数据的聚合查询。首页通常要同时展示轮播图、最新新闻、推荐产品、企业公告这几个区域如果分别调接口、分别返回数据前端就要发多次请求页面加载会明显变慢。我用了异步初始化缓存思维在service层提供一个聚合查询方法一次查出所有首页区块所需数据封装成一个Map或一个IndexVO返回给前端。后期加了Redis缓存首页的响应时间稳定在20毫秒以内。第二个是通用的内容列表分页。前台新闻列表、产品列表、招聘列表都需要分页。我封装了一个PageResult对象统一接收当前页码、每页数量、总记录数、当前页数据这四个信息。MyBatis-Plus自带分页插件配置一个拦截器即可Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这里一个小坑分页插件必须配置在MyBatis-Plus的拦截器链中如果你的项目里同时用了其它MyBatis拦截器要注意顺序否则分页SQL可能不生效。我早期做过一个项目自定义拦截器和分页拦截器顺序不对导致分页总数一直为0排查了整整一天。第三个是留言功能的前后端校验。企业门户的留言表单最怕的是垃圾信息。我在前端做了必填项和手机号格式校验后端再用Hibernate Validator做一次同样的校验这样能挡住直接绕过前端用接口调用的请求。留言表设计时特意加了status字段默认状态是待审核后台审核通过才在前台展示。这一点即使需求方没有提我也坚持做了后来果然派上了用场——留言功能上线第二周就收到好几条广告留言全部被审核机制拦住了。4.3 后台管理权限控制与内容管理的核心实现后台管理是企业门户系统的操盘中心除了栏目和内容的增删改查权限控制是我不愿意妥协的一块。一个支持多角色的后台核心是三个东西身份认证、权限拦截、菜单动态生成。身份认证我用Spring Security实现自定义了一个UserDetailsService从admin_user表里查出用户信息校验密码后生成一个JWT令牌返回给前端。这里坦白讲用Spring Security做表单登录和接口鉴权配置量比Shiro大但它对多角色的支持更原生尤其是方法级别的权限控制一个PreAuthorize(hasRole(ADMIN))注解就能搞定。权限拦截不只是拦住非法的请求还承担了一个重要职责菜单动态展示。我设计了一套基于RBAC模型的权限体系管理员登录后根据角色查询能访问的菜单前台只渲染这些菜单项。这样市场部的人登录后台看不到系统管理的入口管理员登录能看到全部菜单。这套逻辑不复杂却是很多“毕设级”项目最缺失的部分不少门户后台是所有人都能直接进系统管理页面这在真实企业场景里是绝对不能接受的。内容管理模块里富文本编辑器和图片上传是两大核心。富文本我用的是UEditor因为它是国内用得最多、文档最全的编辑器虽然官方维护不积极了但成熟稳定。图片上传做了一个统一接口设计了按日期分目录存储比如/uploads/2025/06/15/时间戳.jpg这样管理图片时按时间维度非常方便。上传后返回图片URL富文本编辑器直接把URL插入内容即可。图片上传这里有个极其常见的问题就是文件存储路径和访问路径不一致。我见过很多新手图片存到了本地磁盘的某个目录前端页面却用项目的静态资源路径去访问结果404。我的做法是上传接口返回的URL使用可配置的全局前缀比如/upload/**在Spring Boot里配置一个资源映射把这个路径映射到实际存储目录。Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }这个配置解决了本地开发的路径映射但要注意部署到服务器后uploadPath如果写在配置文件的相对路径里可能会因为启动目录不同而找不到图片。最稳妥的方式是在配置文件中配置一个绝对路径比如Linux下的/opt/data/portal/upload/Windows下的D:/portal/upload/启动时打印给运维人员确认。5. 实战中遇到的高频问题和解决办法5.1 静态资源404与拦截器冲突前台页面加载不出CSS和JS是最典型的JavaWeb问题。排查思路很简单第一件事就是看请求的URL确认是不是静态资源路径被拦截了。我在这里栽过跟头曾经在Spring Security的拦截规则里把所有非登录接口都拦下来忘了放行静态资源导致登录页面的CSS全部404。解决方式是配置白名单把静态资源路径、登录接口、上传文件访问路径都放行.antMatchers(/css/**, /js/**, /images/**, /upload/**, /login, /portal/**).permitAll()还有一个隐藏很深的坑如果项目里同时使用了Spring MVC的拦截器和Spring Security那么静态资源的放行必须在两边都配置。只配了Security不配MVC拦截器同样会被拦住。我第一次排查这个问题时一度怀疑是资源路径写错了折腾半天才发现是两套拦截机制叠加导致。5.2 中文乱码问题中文乱码在企业门户项目里几乎是必现的因为前后台都要处理新闻标题、产品名称这些中文内容。乱码的根因无非三类数据库编码不对、请求编码不对、响应编码不对。数据库层面建库时就要明确用utf8mb4字符集连接参数里加上characterEncodingutf8useUnicodetrue。这里特别说一下utf8mb4和utf8的区别utf8在MySQL里最多支持3字节的字符像一些生僻字和emoji是存不进去的用utf8mb4才是完整覆盖Unicode的字符集。请求和响应编码Spring Boot里最简单的方式是配置一个CharacterEncodingFilter强制使用UTF-8。但注意这个过滤器要放在最前面执行如果被业务拦截器抢先处理了请求后面再设置编码就来不及了。我见过不少人的乱码问题其实是配置顺序搞错了。5.3 上传功能的各种坑上传图片不成功、上传大图超时是后台管理功能里被吐槽最多的问题。Spring Boot默认的单文件上传大小限制是1MB企业门户后台要经常上传产品大图动辄2~3MB直接就被拦住了。在配置里调大限制spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB这里有个细节max-file-size是单个文件的最大值max-request-size是一次请求中多个文件的总大小。只调前者不调后者前端连传三张大图时照样报错。还有个问题容易被忽略就是上传图片的格式校验。不要只靠前端限制文件类型因为接口可以被绕过。后端一定要做校验包括扩展名白名单比如只允许jpg、png、gif、webp以及文件真实内容校验判断文件头魔数。5.4 多模块协作中的依赖陷阱多模块工程跑起来之后最常见的报错就是ClassNotFoundException和NoSuchMethodError。ClassNotFoundException通常是模块之间没有正确添加依赖打开IDEA的Project Structure确认一下依赖关系就能发现。NoSuchMethodError则更隐蔽多半是jar包冲突两个模块依赖了同一个库的不同版本。解决思路是统一版本号这就是父工程里dependencyManagement存在的意义子模块不要自己指定不必要的版本号一切交给父工程管理。还有一个非常容易踩的坑是改了common模块里的工具类但依赖common的system模块没有重新构建导致运行时用的还是旧代码。Maven多模块开发时每次改完子模块代码务必要对依赖它的模块也执行一次install或者直接对整个工程执行clean install。这件事看起来不起眼但在多人协作时经常导致“我明明改了代码运行结果没变化”的尴尬局面。5.5 门户前台访问速度慢企业门户对访问速度的要求是天然的一个首页加载5秒的官网不管是客户还是老板都接受不了。我做的性能优化主要分三层。第一层是数据库优化列表页都加了必要的索引比如article表的status、create_time字段以及product表的product_category_id字段。查询时尽量用MyBatis-Plus的LambdaQueryWrapper避免手写拼接SQL导致的注入风险。第二层是缓存优化首页的数据查询结果缓存到Redis缓存时间设为5分钟并提供一个后台“一键刷新缓存”的按钮。管理员在后台改了新闻或产品点击按钮或者设置定时任务让缓存自动失效。这个设计让页面响应速度和运营实时性做到了兼顾。第三层是静态资源配置Nginx上加了对静态资源文件的expires设定让浏览器强缓存图片、CSS和JS文件。这个优化效果最明显几乎把静态资源请求的量级直接砍掉了绝大部分。6. 项目完成后我的一些实际操作体会这个企业门户多模块系统做下来我最深的体会是JavaWeb项目最考验人的往往不是某个框架有多熟而是对整个系统边界的理解。多模块的拆分不是给简历上多写一行“熟练使用Maven多模块”而是一种真正让代码更好维护、更好协作的组织方式。有两点实操经验我想单独拿出来说。第一点多模块工程里的模块命名一定要有极强的一致性。我见过有人用portal、core、manager三种风格来命名模块结果半年后自己都分不清哪些代码放在哪个模块。我在这个项目里统一用portal-前缀然后按职责分portal-common、portal-system、portal-web并且把main函数放在portal-web模块父工程和common模块都不包含启动类。第二点后台表格列的展示需求一定要提前跟运营确认。企业门户后台的内容列表看起来是简单的表格但不同的运营人员对字段的诉求差异很大。有的要看发布人有的只看发布时间有的要在列表里直接看到封面图。如果前期不确认好后期改表格列的频率会非常高而每次都涉及前端表格渲染和后端实体类返回改起来很痛苦。我的做法是列表查询接口直接返回一个专门的ListVO把可能需要的字段都包含进去宁可前端渲染时不用也不要在后期反复改接口。如果你也是正在做JavaWeb企业门户或者在准备相关项目的设计希望这篇内容能帮你避开我踩过的坑。这个系统后续如果要扩展我个人觉得比较有价值的方向是接入单点登录给企业内部的多个子系统提供统一的身份认证以及把前台门户的首页数据用更成熟的内容分发策略做优化实现真正的动态化运营。这些在现有架构下都能稳妥地扩展毕竟模块边界已经留好了位置。