企业门户网站这类项目，在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：业务实现
- mapper：MyBatis的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核心配置大致是这样：
<groupId>com.example</groupId> <artifactId>portal-parent</artifactId> <version>1.0.0</version> <packaging>pom</packaging> <modules> <module>portal-common</module> <module>portal-system</module> <module>portal-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字符集，连接参数里加上characterEncoding=utf8&useUnicode=true。这里特别说一下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企业门户或者在准备相关项目的设计，希望这篇内容能帮你避开我踩过的坑。这个系统后续如果要扩展，我个人觉得比较有价值的方向是接入单点登录，给企业内部的多个子系统提供统一的身份认证，以及把前台门户的首页数据用更成熟的内容分发策略做优化，实现真正的动态化运营。这些在现有架构下都能稳妥地扩展，毕竟模块边界已经留好了位置。
