简介：这份PDF文档面向通信工程、网络工程等专业的学生及中小企业网络运维人员，围绕小型局域网与企业信息中心办公系统的组网需求，提供一套完整的课程设计级方案。内容从需求分析入手，梳理信息中心网络的特点与设计原则，进而展开网络技术选型、内部局域网结构设计、服务器配置与外网结构规划，并给出拓扑图、IP分配方案及综合布线实施要求，重点阐述局域网的设计思想、解决方案与管理方法。资源包内仅含1个PDF文件，约1.95MB，篇幅紧凑，适合作为课程设计参考或组网入门读物。文档目录涵盖摘要、需求分析、网络技术选择、网络结构设计、拓扑图与结果、网络布局与综合布线及致谢等模块，结构完整，便于按章节查阅。目前已有180人学习，适合需要快速理解局域网组网流程、借鉴拓扑与布线思路的读者参考使用。
1. 局域网办公系统：从一根网线到一套能跑的业务闭环
很多团队第一次做局域网办公系统，都是被现实逼出来的：外网时通时断，文件传来传去版本满天飞，审批靠吼、考勤靠表、通知靠群。于是有人丢来一个标题——“小型局域网以及企业局域网办公系统的设计与实现”，听起来像毕设，其实是一套非常务实的工程命题：在局域网内，把办公系统真正跑起来，让几十到几百号人每天用得上、用得稳。
这套东西适合谁？一是中小团队里被临时抓来搭内部系统的后端或运维；二是需要在内网做一套可交付办公平台的开发者；三是想把现有外网系统“内网化”的负责人。它解决的不是“有没有系统”，而是“在内网这种受限环境里，怎么把登录、文件、审批、通知、权限这些事串成闭环”。下面按选型、落地、避坑、进阶四段推进，能抄的步骤我都给到命令和参数。
2. 局域网办公系统选型：为什么不是随便找个开源后台改改
2.1 先定边界：小型局域网和企业局域网差在哪
很多人把“小型局域网”和“企业局域网”当成一个东西，实际落地时差别很大。小型局域网通常是一台普通服务器或一台高配 PC，几十个终端，网络结构扁平，没有 VLAN，没有独立机房，甚至没有固定公网出口。企业局域网则往往有网段划分、域控、防火墙策略、代理上网、终端准入，服务器可能跑在虚拟化平台上，运维有变更流程。
这个差别直接决定技术选型。小型场景优先“单机可跑、依赖少、部署快”，能用一个 jar 包加一个数据库搞定就别上微服务。企业场景优先“可集成、可审计、可扩展”，要能对接现有账号体系、日志平台和备份策略。把这两类混着做，最常见的结果是：小团队被一堆中间件拖死，大企业被一个玩具系统卡住。
从功能上看，办公系统的核心模块其实很稳定：用户与组织、角色权限、文件共享、通知公告、审批流、考勤或日程。真正拉开差距的是权限模型和文件管理，这两块做不好，后面全是补丁。
2.2 技术栈怎么选：Spring Boot + Vue 仍是内网最稳的组合
内网办公系统不需要追新，稳定和可维护性压倒一切。我一般推荐后端 Spring Boot，前端 Vue，数据库 MySQL 或 PostgreSQL，文件存储先用本地磁盘或挂载的 NAS。原因很直接：生态成熟，遇到问题能搜到答案；打包简单，一个可执行 jar 加一个前端静态目录就能跑；内网环境没有外网依赖，Maven 和 npm 依赖提前在能联网的机器上拉好，做成离线仓库。
如果团队 Java 人手不足，用 Python 的 FastAPI 或 Django 也能做，但要注意内网部署时的依赖打包，pip 的离线 wheel 比 Maven 仓库更容易踩坑。前端如果不想引入构建链，用服务端模板加少量原生 JS 也能交付，只是后期交互复杂了会难受。
数据库选型上，小型场景 MySQL 足够，企业场景如果已有 Oracle 或 SQL Server，优先复用，减少运维负担。文件存储不要一上来就上对象存储，内网里 MinIO 是不错的折中，但单机部署时本地目录加定期备份更省事。
2.3 权限模型：RBAC 够用，但别把组织树和角色混在一起
权限是办公系统的地基。常见做法是 RBAC：用户属于角色，角色拥有权限，权限对应菜单和接口。听起来简单，翻车点在于把“部门”和“角色”混为一谈。部门是组织属性，决定数据可见范围；角色是职能属性，决定能做什么操作。两者混在一起，后面加一个“跨部门审批”就要重构。
我一般会建三张核心表：用户表、角色表、权限表，再加用户角色关联和角色权限关联。数据权限单独用一张“数据范围”配置，支持本人、本部门、本部门及下级、全部四种。这样审批流里“谁能看哪些单子”就有统一出口，不用在每个查询里写 if-else。
-- 用户角色关联：一个用户可以有多个角色 CREATE TABLE sys_user_role ( user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, PRIMARY KEY (user_id, role_id) ); -- 角色权限关联：权限码形如 file:upload、approve:audit CREATE TABLE sys_role_permission ( role_id BIGINT NOT NULL, perm_code VARCHAR(64) NOT NULL, PRIMARY KEY (role_id, perm_code) ); -- 数据范围：scope_type 取 SELF/DEPT/DEPT_SUB/ALL CREATE TABLE sys_data_scope ( role_id BIGINT NOT NULL, scope_type VARCHAR(16) NOT NULL, PRIMARY KEY (role_id) );上面三张表的关键在于把“功能权限”和“数据权限”拆开。功能权限用权限码在接口层拦截，数据权限在查询层拼 SQL 条件。参数上，scope_type 的四个取值要提前和业务确认，尤其是 DEPT_SUB 需要组织树支持递归查询，MySQL 里可以用递归 CTE 或维护一张闭包表。
3. 把系统在内网跑起来：部署、文件共享与通知的最小闭环
3.1 内网部署的最小命令：从 jar 包到可访问
假设后端已经打成 office.jar，前端构建产物在 dist 目录，服务器是内网一台 Linux。最小部署不需要 Docker，直接跑 jar 加 Nginx 托管静态文件即可。先确认服务器有 JDK 17 和 MySQL，然后建库建用户。
# 建库和专用账号，避免用 root 跑应用 mysql -uroot -p -e "CREATE DATABASE office DEFAULT CHARSET utf8mb4;" mysql -uroot -p -e "CREATE USER 'office'@'%' IDENTIFIED BY 'StrongPass123';" mysql -uroot -p -e "GRANT ALL ON office.* TO 'office'@'%'; FLUSH PRIVILEGES;" # 启动后端，指定内网端口和数据库连接 nohup java -jar office.jar \ --server.port=8080 \ --spring.datasource.url="jdbc:mysql://127.0.0.1:3306/office?useSSL=false&serverTimezone=Asia/Shanghai" \ --spring.datasource.username=office \ --spring.datasource.password=StrongPass123 \ > office.log 2>&1 &这段命令里，server.port 选 8080 是为了避开 80 端口可能被其他服务占用；数据库连接串里的 useSSL=false 在内网可接受，但如果企业有安全要求就开启并配置证书。nohup 加 & 让进程后台运行，日志重定向到 office.log，排查时先看这个文件的前 50 行。
前端用 Nginx 托管，配置里把 /api 反向代理到后端，避免跨域。
server { listen 80; server_name office.local; root /opt/office/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }try_files 那行是给前端路由用的，刷新页面不会 404。proxy_set_header 把真实 IP 传给后端，审计日志里才有意义。改完配置用 nginx -t 检查，再 nginx -s reload。
3.2 局域网文件共享：别用共享文件夹硬扛，走应用层
内网办公系统里文件模块最容易翻车。很多人图省事，直接让用户访问 Windows 共享文件夹，结果权限乱、版本乱、审计没有。正确做法是文件走应用层：上传、下载、预览都经过系统，权限由系统控制，存储落在服务器目录或 NAS。
上传接口要限制大小和类型，分片上传用于大文件。下面是一个 Spring Boot 里限制上传大小的配置片段。
spring: servlet: multipart: max-file-size: 200MB max-request-size: 500MB file-size-threshold: 2MBmax-file-size 是单文件上限，max-request-size 是整次请求上限，分片上传时后者要大于分片大小。file-size-threshold 是写入磁盘的阈值，小文件先放内存。参数怎么定？看内网带宽和用户耐心，200MB 对多数办公文档足够，图纸或视频再调大。
存储路径建议按日期和业务类型分目录，文件名用 UUID 加原扩展名，数据库里存原文件名和相对路径。这样既避免中文名和特殊字符问题，也方便备份脚本按目录增量同步。
3.3 通知与审批：内网没有推送通道，就用轮询加站内信
内网环境往往没有外网推送服务，通知只能靠站内信加轮询。前端每隔 30 秒请求一次未读数量，有新的就提示。审批流用状态机实现，每个节点记录处理人和时间，避免“谁批的”说不清。
审批表设计上，主表存单据信息，明细表存节点流转记录。状态字段用枚举：待提交、审批中、已通过、已驳回、已撤回。每次流转写一条明细，包含节点名、处理人、处理意见、时间。这样查历史时直接按单据 ID 查明细，不用解析日志。
轮询间隔别设太短，30 秒是内网可接受的折中，太短会给服务器压力，太长用户觉得卡。如果企业有 WebSocket 条件，可以升级为长连接，但要注意内网防火墙对长连接的超时策略。
4. 局域网办公系统避坑：那些让我加班到凌晨的细节
4.1 坑一：内网 IP 冲突导致服务时好时坏
现象是系统偶尔打不开，过一会儿又正常，重启服务也没用。原因是服务器 IP 和某台终端冲突，或者 DHCP 分配了重复地址。解决方法是给服务器配静态 IP，并在交换机或路由器上做 IP-MAC 绑定。排查时用 arping 或 arp -a 看是否有重复 MAC。
4.2 坑二：文件上传后中文名乱码
现象是上传成功但下载时文件名变成乱码。原因是响应头里的文件名没有做 URL 编码，或者 Tomcat 的 URI 编码配置不对。解决方法是下载时用 URLEncoder 编码文件名，并在 application.yml 里设置 server.tomcat.uri-encoding 为 UTF-8。数据库和表也要确认是 utf8mb4。
4.3 坑三：权限改了不生效，用户还在用旧缓存
现象是管理员改了角色权限，用户刷新页面还是能看到旧菜单。原因是权限数据被缓存在 JVM 或前端 localStorage。解决方法是在权限变更时主动清缓存，前端登录后重新拉取权限，后端用带版本号的缓存键。别依赖用户手动清浏览器缓存。
4.4 坑四：数据库连接池耗尽，系统卡死
现象是并发一高，接口全部超时，日志里出现“等待连接超时”。原因是连接池最大连接数设得太小，或者有慢查询占着连接不放。解决方法是把 HikariCP 的 maximum-pool-size 调到 CPU 核数的 2 到 4 倍，同时开启慢查询日志，找出超过 1 秒的 SQL 加索引。
4.5 坑五：备份只备了数据库，文件丢了
现象是数据库恢复后，文件下载全部 404。原因是备份脚本只 mysqldump，没同步文件目录。解决方法是备份脚本里同时打包数据库和文件存储目录，并定期做恢复演练。备份文件不要放在同一台服务器上，内网里至少同步到另一台机器或 NAS。
5. 进阶：让局域网办公系统扛住真实使用的三个技巧
第一个技巧是给关键接口加限流。内网虽然用户少，但一个死循环的前端轮询就能把服务打满。用 Spring Boot 的拦截器加令牌桶，对登录、上传、审批提交这几个接口单独限流，阈值按实际并发压测结果定。压测用 JMeter 在内网另一台机器上跑，别在服务器本机跑，否则数据不准。
第二个技巧是日志分级和归档。内网排查问题全靠日志，但日志写太多会占满磁盘。我一般把日志按天切割，保留 30 天，ERROR 级别单独存一份并配置邮件或站内信告警。日志里不要打印密码和完整身份证号，审计要求高的场景要做脱敏。
第三个技巧是版本升级要能回滚。内网升级不像外网可以随时热修，每次升级前备份数据库和旧 jar 包，升级后先在内网测试账号上验证核心流程，再通知全员。回滚脚本要提前写好，别等出事了再手忙脚乱。
| 检查项 | 小型局域网建议值 | 企业局域网建议值 |
|---|---|---|
| 服务器 IP | 静态 IP + IP-MAC 绑定 | 静态 IP + 网段规划 |
| 数据库连接池 | 10 到 20 | 按并发压测调整 |
| 文件上传上限 | 200MB | 按业务类型分级 |
| 日志保留 | 30 天 | 90 天并归档 |
| 备份频率 | 每日全量 | 每日增量 + 每周全量 |
这张表是我踩坑后总结的底线值，实际项目按业务量调整。最后说个习惯：每次上线新功能，我都会用一个普通员工账号从头走一遍流程，从登录到审批到下载文件，不走管理员账号。管理员视角永远看不到普通用户的痛。希望帮到你。
本文还有配套的精品资源，点击获取
