企业官网建设流程全解析

1. 项目背景与需求拆解

1.1 派出所消防台账管理的实际痛点

派出所的消防台账管理，听起来是个不起眼的小事，但真正做过的人都知道，里面的坑一点不比大厂业务系统少。以前手工做台账的时候，纸质检查表、Excel 统计、微信报备的零散照片混在一起，每逢季度检查就得翻箱倒柜补记录，数据对不上、日期对不齐、签字补不完，这些都是常态。更麻烦的是，"九小场所"（小商店、小餐饮、小旅馆这类小型场所）数量多、分布散，每家场所的检查周期、隐患状态、整改负责人都不一样，靠人肉记忆根本管不过来。

这个项目就是冲着这些问题去的。核心目标很明确：用一套 web 系统把派出所辖区内的消防检查、隐患登记、整改跟踪、台账归档全部线上化，让基层民警或辅警在电脑上、平板上就能完成从"发现隐患"到"闭环整改"的完整流程。系统前端使用 Vue 开发，配合组件化、路由管理、状态管理这些成熟方案，保证界面交互流畅、开发维护成本可控。

再说说这套系统适合谁来参考。如果你是刚入门 Vue、想找一个完整业务场景练手，这个项目能让你把路由、状态管理、组件通信、接口封装这些知识点全部串起来；如果你已经在做管理类系统，这里的排查记录、分页搜索、权限路由、图表统计模块都能直接借鉴。它不涉及太复杂的前端架构，但业务逻辑足够真实，能帮你理解"一个能交付给用户使用的系统"和"一个 demo"之间的差距。

1.2 为什么前端选择 Vue

选 Vue 而不是 React 或者原生 JS，主要基于三个层面的考虑。

第一是上手门槛和团队承接能力。派出所这类政务信息化项目，往往不是大厂专业前端团队维护，通常是外包公司或者单位内部的技术人员跟进。Vue 的模板语法接近 HTML 习惯，单文件组件（SFC）结构清晰，新成员接手代码时看template、script、style三块结构的成本远低于去理解 JSX 和函数式组件的抽象逻辑。

第二是对已有技术栈的兼容性。这个项目是典型的"前端 Vue + 后端 Spring Boot"前后端分离架构，Vue 生态里的 vue-router、Pinia/Vuex、Axios 都是久经考验的成熟库，与后端接口对接的套路非常固定，网上资料丰富，遇到问题几乎都能搜到现成答案。对于派出所这种对稳定性和交付周期都有硬性要求的项目，选成熟方案永远比选新潮方案稳妥。

第三是开发效率。政务管理系统有大量重复的"表单 + 列表 + 详情"页面，Vue 的组件化能力可以把这些抽象成公共组件，比如台账录入表单、场所信息列表、状态标签等，一个地方改，全局生效。实际开发下来，公共组件抽得好，能省掉至少 30% 的重复工作量。

1.3 核心功能模块划分

整个系统的功能，按派出所实际业务流拆成了七个核心模块：

模块划分的核心原则是"业务闭环"：从场所建档，到检查记录，到隐患发现，到整改销号，每一步都有数据承接，每一步都能溯源。这也是消防台账管理跟普通 CRUD 系统的本质区别——它不只是记录数据，更重要的是让每一笔数据都能映射到实际业务流程中的具体动作。

2. 技术选型与项目初始化

2.1 前端技术栈与依赖选择

这个项目的技术栈是典型的中后台管理系统配置，每个选择都有实际依据。

核心框架是 Vue 3 + Vite。Vue 3 的 Composition API 在业务逻辑复杂的页面里特别好用，比如台账录入页同时要处理表单校验、图片上传、关联数据回显，用setup语法可以按功能聚合代码，不用像 Options API 那样把同一个功能的代码分散在data、methods、watch里。Vite 做开发服务器，冷启动快、热更新响应快，比起以前的 Webpack 配置，省掉了大量构建配置的时间成本。

路由方案用 vue-router 4，状态管理用 Pinia。路由部分不只是做页面跳转，更重要的是做权限控制——根据不同角色动态生成可访问的路由表。状态管理用来存登录用户的角色信息、全局的场所筛选条件、以及台账列表里跨组件共享的数据。

请求库封装 Axios，这是国内前后端分离项目的标准做法。封装的目的不只是简化调用，更重要的是统一处理接口返回值、错误提示、Token 过期跳转这些横切逻辑。

UI 组件库我选了 Element Plus。原因很简单：派出所的业务人员电脑浏览器大多是 Chrome、Edge，Element Plus 的表格、表单、日期选择器、弹窗这些组件在后台管理系统里品控稳定，文档完整，而且它内置的布局系统能很快搭出符合用户习惯的界面。另一个选择是 Ant Design Vue，但考虑到项目整体风格偏简洁务实，Element Plus 的视觉更清淡一些。

2.2 环境准备与脚手架搭建

开发环境这块，第一步是装 Node.js。注意版本不能太老，Vue 3 + Vite 组合建议 Node 版本在 16 以上，推荐 18 LTS。装完后在终端确认：

node -v npm -v

然后用 Vite 官方脚手架创建项目：

npm create vite@latest fire-ledger-web -- --template vue cd fire-ledger-web npm install

这里说一个我踩过的坑：npm create vite的时候如果不用--template vue，默认会问一堆交互问题，在自动化脚本场景下容易卡住。直接指定模板最省事。

装完基础依赖后，再安装项目必须的包：

npm install vue-router@4 pinia axios element-plus npm install -D sass

Element Plus 这里建议全量引入，别图省事搞按需自动导入。按需导入虽然能减小打包体积，但需要额外配置unplugin-vue-components和unplugin-auto-import，对项目初期来说多了一层复杂度。派出所这种内部系统，用户量不大，全量引入的 JS 体积差异对实际使用者几乎无感，稳定省心优先。

2.3 项目目录结构设计

目录结构是项目长期可维护性的基础。我采用的是按"模块 + 类型"混合拆分的方式：

src/ api/ # 统一接口请求 auth.js place.js inspection.js rectification.js statistics.js assets/ # 静态资源 components/ # 公共组件 TablePage.vue FormDialog.vue StatusTag.vue layout/ # 整体布局 MainLayout.vue SidebarMenu.vue HeaderBar.vue router/ # 路由配置 index.js guard.js stores/ # Pinia 状态管理 user.js app.js placeFilter.js views/ # 页面视图 login/ dashboard/ place/ inspection/ rectification/ archive/ utils/ # 工具函数 request.js format.js App.vue main.js

每个业务模块在views下建一个文件夹，内部放index.vue（列表页）和components/（该模块私有组件）。api目录按后端接口归属拆文件，保持前端调用与后端接口一一对应，不要出现一个文件里堆了几十个接口的情况。

3. 核心模块设计与实现

3.1 登录鉴权与路由守卫

登录模块是整个系统安全的第一道门。派出所的系统对权限要求比普通企业项目更严格——民警、辅警的可见范围不同，网格民警只能看自己网格的场所数据，不能越权访问其他区域。

登录流程是这样的：用户输入账号密码，前端调/api/auth/login获取 Token 和用户信息，Token 存 localStorage，用户信息（包含角色、所属网格）存 Pinia。然后根据角色生成动态路由：

// router/guard.js router.beforeEach((to, from, next) => { const userStore = useUserStore() if (to.path === '/login') { next() return } if (!userStore.token) { next('/login') return } // 动态路由：管理员加载全部路由，普通用户加载部分路由 if (!userStore.routesLoaded) { const accessRoutes = generateRoutes(userStore.role) accessRoutes.forEach(route => router.addRoute(route)) userStore.routesLoaded = true next({ ...to, replace: true }) } else { next() } })

重点关注generateRoutes这个函数。它根据角色返回一份路由配置数组，普通用户的路由里就没有"用户管理""系统设置"这些菜单项。这里有个容易犯的错：只在侧边栏菜单里隐藏并不安全，必须用router.addRoute动态添加路由，确保未授权的路径直接 404。

路由守卫里还有一个细节——点击刷新按钮时，Pinia 里的用户信息会丢失，但 localStorage 里还有 Token。所以main.js初始化时要做一个"重新拉取用户信息"的动作，否则刷新后就跳回登录页，体验很糟。

3.2 台账录入与表单校验

台账录入是使用频率最高的页面，消防检查记录、隐患登记都靠它录入。这个页面的核心难点不在表单本身，而在"如何让用户少填一些字段，同时保证数据质量"。

我的做法是分两步走。

第一步，场所信息联动。检查记录里的"场所名称"用远程搜索下拉框，用户输入关键字，前端调用/api/place/search查出匹配场所，选中后自动回填所属网格、负责人、场所类型、联系电话这些字段。这样一来，用户只需要输入最关键的检查信息，其余字段零操作。

第二步，检查项采用分组动态表单。消防检查项固定分为"消防设施""疏散通道""用火用电""管理制度"几个分组，每组下面若干检查项，每个检查项是"合格/不合格/不适用"三选一。不合格的项自动进入隐患列表，要求填写隐患等级和整改期限。

// 动态表单核心逻辑 const checkGroups = ref([]) const addCheckItem = (groupIndex) => { checkGroups.value[groupIndex].items.push({ name: '', status: 'qualified', // qualified: 合格, unqualified: 不合格, na: 不适用 remark: '' }) } const submitForm = async () => { const unqualifiedItems = [] checkGroups.value.forEach(group => { group.items.forEach(item => { if (item.status === 'unqualified') { unqualifiedItems.push({ group: group.name, item: item.name, level: item.level, remark: item.remark }) } }) }) if (unqualifiedItems.length > 0) { // 存在不合格项，提交检查记录的同时自动创建隐患单 await api.createInspectionWithIssues(payload, unqualifiedItems) } else { await api.createInspection(payload) } }

这里需要强调一个很重要的业务逻辑：检查记录和隐患单不能是孤立的两张表，而应该通过业务 ID 关联。一次检查发现 3 个隐患，提交后自动生成 3 条隐患记录，每条记录关联到这次检查的 ID，这样后续整改时能反查是哪次检查发现的。

表单校验方面，我用的是 Element Plus 自带的el-form校验规则，加上一些自定义 validator。比如"整改期限必须晚于今天""隐患等级为重大时必须填写现场照片""整改责任人不能为空"这类跨字段校验。自定义校验器写多了以后，我会把它们统一抽到一个validators.js文件里，避免每个页面重复写。

3.3 数据列表与搜索分页

消防台账的列表页是另一个高频页面，检查记录列表、隐患列表、整改列表都长得很像，所以我封装了一个通用TablePage组件。这个组件把"搜索表单 + 表格 + 分页"三件套统一封装，业务页面只需要传配置项：

// 使用示例 const pageConfig = { searchFields: [ { prop: 'placeName', label: '场所名称', type: 'input' }, { prop: 'checkResult', label: '检查结果', type: 'select', options: [ { label: '全部', value: '' }, { label: '合格', value: 'qualified' }, { label: '不合格', value: 'unqualified' } ]}, { prop: 'checkDateRange', label: '检查日期', type: 'daterange' } ], columns: [ { prop: 'placeName', label: '场所名称', minWidth: 160 }, { prop: 'checkDate', label: '检查日期', minWidth: 120 }, { prop: 'inspector', label: '检查人', minWidth: 100 }, { prop: 'checkResult', label: '结果', slotName: 'resultTag' }, { prop: 'action', label: '操作', fixed: 'right', width: 180 } ] }

分页逻辑必须用后端分页，不要前端一次性查全量再slice。一个辖区几千家场所、半年检查记录几万条，全量查询到浏览器后页面直接卡死。请求参数是pageNum和pageSize，后端返回total字段，前端收到total后更新分页组件里的总条数。

搜索条件里要注意一点：日期范围传给后端的时候，要把数组格式转成startDate和endDate两个独立参数，或者转成YYYY-MM-DD格式的字符串，不要直接传数组。前后端联调时很多日期查不出来，都是因为这个格式没对齐。

3.4 可视化统计看板

统计看板这个模块是后来才加的需求，领导希望打开系统第一眼就能看到辖区消防情况的整体概貌。我使用的是 ECharts 图表库，配合 Vue 封装ChartCard组件。

看板包含四个核心图表：

• 辖区场所类型分布（饼图）
• 近十二月检查数量趋势（折线图）
• 各网格隐患数量排名（横向柱状图）
• 隐患整改状态漏斗（漏斗图）

图表组件最需要注意的是异步数据更新问题。ECharts 实例创建后，如果数据是异步加载的，必须在setOption前确认 DOM 已经渲染完成。我在实践中是这么处理的：

import * as echarts from 'echarts/core' onMounted(async () => { chartInstance = echarts.init(chartRef.value) const data = await api.getStatistics() chartInstance.setOption({ // ...配置项，数据来自 data }) window.addEventListener('resize', resizeHandler) }) onBeforeUnmount(() => { window.removeEventListener('resize', resizeHandler) chartInstance.dispose() })

还有一点，ECharts 按需引入很重要。全量引入的包大约 1MB 以上，对一个内部管理系统来说确实臃肿。我用的是echarts/core按需注册的方式，只引入用到的PieChart、LineChart、BarChart、FunnelChart，体积能降到原来的三分之一。

4. 前后端协作与接口联调

4.1 接口设计规范

前后端联调是管理类项目开发中耗时最长的环节，很多问题不是技术难度大，而是两边对接口的约定不一致。这个项目在开发前我先定了一份接口规范，后端同事照着标准实现，前端照着标准调用，联调效率明显提升。

接口统一采用 RESTful 风格，路径以资源为中心：

POST /api/auth/login 登录 POST /api/auth/logout 退出 GET /api/place/page 场所分页查询 POST /api/place 新增场所 PUT /api/place/{id} 修改场所 DELETE /api/place/{id} 删除场所 GET /api/inspection/page 检查记录分页 POST /api/inspection 新增检查记录 GET /api/issue/page 隐患分页查询 PUT /api/issue/{id}/status 更新隐患状态 GET /api/statistics/overview 统计看板数据

响应体统一封装成下面这种格式：

{ code: 200, message: 'success', data: { total: 100, list: [], pageNum: 1, pageSize: 10 } }

值得注意的是，前端 Axios 封装里要能同时处理三种情况：HTTP 状态码是 200 但业务code不是 200 的情况、HTTP 状态码直接 401/403/500 的情况、网络异常（断网、超时）的情况。我统一在响应拦截器里处理，前端页面代码只需要拿data，不需要每个页面都写错误判断。

4.2 Axios 封装与请求拦截

Axios 封装是整个前端请求层的基础设施，我把代码都集中在一个utils/request.js文件里。

核心逻辑有三块。

第一块是请求拦截器，自动在请求头带上 Token：

service.interceptors.request.use( config => { const userStore = useUserStore() if (userStore.token) { config.headers['Authorization'] = `Bearer ${userStore.token}` } return config }, error => Promise.reject(error) )

第二块是响应拦截器，统一处理业务状态码：

service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response?.status === 401) { // Token 过期，清除本地登录态并跳转登录 const userStore = useUserStore() userStore.reset() router.push('/login') ElMessage.error('登录状态已过期，请重新登录') } else { ElMessage.error(error.message || '网络异常') } return Promise.reject(error) } )

第三块是请求超时设置和取消重复请求。管理类系统里用户经常双击提交按钮，导致同一条记录被插入两次。我的解决方法是封装一个"提交锁"，记录请求的 URL + 参数，在短时间内相同请求直接拒绝：

const pendingRequests = new Map() const addPendingRequest = (config) => { const requestKey = `${config.method} ${config.url} ${JSON.stringify(config.data || config.params)}` if (pendingRequests.has(requestKey)) { return false } pendingRequests.set(requestKey, true) return true }

这个方法实测下来防重复提交很有效，尤其是"提交检查记录"这种高频且不可撤销的操作。

4.3 与后端联调的典型问题

联调阶段遇到最多的问题有三个，我都记录下来供参考。

第一个是跨域问题。前后端分离项目，前端开发服务器在localhost:5173，后端接口在localhost:8080，浏览器默认跨域拦截。解决办法是在 Vite 配置里加代理：

// vite.config.js server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

前端请求路径写/api/auth/login，Vite 开发服务器自动转发到http://localhost:8080/api/auth/login。生产环境则通过 Nginx 反向代理解决。

第二个是日期格式问题。后端返回的日期字段可能是2025-01-15T10:30:00这种 ISO 格式，也可能带时区后缀，前端展示要格式化成2025-01-15。我在utils/format.js里封装了formatDate方法，所有日期填充用同一个函数，避免每个页面各写一套。

第三个是字段命名不一致。后端习惯用小驼峰placeName，但也有老系统返回下划线place_name。联调时最稳妥的办法是跟后端统一用驼峰命名，实在改不了后端，就在 Axios 响应的 transform 里做一层递归转换，把下划线键名转成驼峰，不要让页面里的数据字段风格混乱。

5. 常见问题与排查技巧实录

5.1 开发环境问题速查

我整理了开发过程中最常踩的 7 个坑，按问题现象、原因、解决方案列表如下：

5.2 构建部署与打包优化

项目开发完后要打生产包，这个环节同样有几个讲究。

打包命令是npm run build，产物会输出到dist目录。我遇到过的实际问题是打包后路由变成 history 模式，直接访问子路径会 404。后端用 Nginx 部署时需要在location块里配置 try_files：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

这是因为 Vue Router 的 history 模式本质上是前端路由，刷新浏览器时服务器找不到对应的物理文件路径，必须回退到index.html，再由前端路由解析。

打包体积优化我做了两件事。第一件是前面提到的 ECharts 按需引入。第二件是手动拆分代码块，把element-plus单独打成一个大 chunk，把业务代码分散到各自的路由 chunk，这样首屏不用一次性加载所有页面的 JS：

// vite.config.js build: { rollupOptions: { output: { manualChunks: { 'element-plus': ['element-plus'], 'echarts': ['echarts/core'] } } } }

5.3 用户体验细节优化

系统交付给用户使用后，反馈最好的是几个意料之外的小细节，这里分享给大家。

第一是列表页的批量操作。派出所的网格民警习惯是"一次检查十家场所，记录统一提交"，所以检查记录列表支持多选然后批量导出或批量归档，比一条条操作效率高得多。

第二是搜索条件的记忆功能。用户经常在同一个网格反复查看数据，我把搜索条件存在 Pinia 里，切换菜单再回来，筛选条件还在，不用重设。

第三是"逾期标红"。整改期限过了还没整改销号的隐患记录，在列表里自动红字标注，这是用户明确提出的需求，也是台账管理里最实用的功能。实现上很简单，后端返回dueDate和status，前端计算if (status === 'processing' && dueDate < today)就添加红色 class。

第四是导出功能。台账归档要能一键导出 Excel，我用xlsx这个库实现前端导出：

import * as XLSX from 'xlsx' const exportData = async () => { const allData = await api.getAllExportData() const worksheet = XLSX.utils.json_to_sheet(allData) const workbook = XLSX.utils.book_new() XLSX.utils.book_append_sheet(workbook, worksheet, '消防台账') XLSX.writeFile(workbook, `消防台账_${new Date().toLocaleDateString()}.xlsx`) }

这里要提醒一句：如果数据量大，不要用前端导出，直接走后端接口生成 Excel 文件返回下载链接。前端导出适合几百条的数据量，超过几千条浏览器会卡。

5.4 关于 Vue 版本和生态选型的一点题外话

项目过程中我一直关注社区里 Vue 相关的讨论，有个现象值得聊聊：网上关于 "Vue 和 React 的区别""Vue 源码解析" 这类话题热度一直很高，但落到实际项目里，大多数管理系统用到的只是 Vue 生态的表层能力——组件、路由、状态管理、请求封装。

我的看法是，不要被"必须深入源码才能写好业务系统"这种论调吓到。Vue 的源码设计和响应式原理确实值得学习，它能帮你在遇到性能问题时有更清晰的排查方向，但在做派出所台账这类业务系统时，更重要的是对业务流的理解、对用户操作习惯的把握、对数据一致性的重视。前端框架只是手段，把用户从繁琐的纸质台账里解放出来，这才是项目的核心价值。

技术上有一个点我建议初学者可以了解一下：Vue 3 的 Composition API 和reactive/ref响应式基础。我用原生Proxy手写过类似的迷你响应式系统，对理解 Vue 的依赖收集和触发更新机制帮助很大。比如ref处理基本类型需要包一层.value，本质是因为Proxy只能代理对象，不能直接代理基本类型。这些知识不会直接体现在页面效果上，但排查复杂 bug 时非常有用。

6. 项目经验总结与扩展建议

6.1 这套架构还能复用到哪些场景

做完这个项目我发现，消防台账管理系统本质上是一套"基于 Vue 的区域性巡查-隐患-整改闭环管理平台"，它的架构和代码稍加改造就能复用到很多类似场景。

比如社区网格化管理中的食品安全巡查记录、城市管理中"门前三包"责任落实台账、校园安全巡查、养老机构的日常安全检查，这些都是同一套业务模型：建立受检对象档案，定期巡查录入，发现问题登记，限期整改销号，最后按周期汇总台账展示效果。换一个业务场景，只需要改数据字典、改几个表单字段、换一套统计图表的指标，整体框架完全不用动。

这也是当初我没有把"消防"两个字写死在代码里的原因。所有业务词汇通过数据字典配置，比如场所类型、检查项、隐患等级这些，都是数据库里的字典表，前端从接口拉取渲染，而不是写在页面里。这样将来要复用，不需要改前端代码，只需要后端换一套字典数据。

前端还有一个值得抽离的部分是TablePage组件和FormDialog组件。我把这两个组件做得足够通用之后，新加一个业务模块的页面只需要 20 分钟左右：配置搜索字段、配置表格列、配置表单字段，完成。这套东西在后续所有管理类项目里都能直接搬过去用，省下的时间远不止当初写组件的那些功夫。

6.2 几个值得继续优化的方向

系统目前跑得挺稳，但回头看还是有几个优化空间比较大的地方。

第一个是移动端适配。派出所民警经常要出门检查，如果在检查现场能用手机拍照上传隐患照片，比回到电脑前再补录效率高很多。目前系统在手机浏览器上能用，但体验一般，后续可以接入 H5 端或者小程序端，让检查人员在现场就能完成录入。这里 Vue 生态里可以用vant这类移动端组件库快速改造。

第二个是图片压缩。隐患照片动辄几 MB，直接上传到服务器既占空间又拉慢加载速度。前端在input[type=file]的change事件里用 Canvas 做一次等比压缩，再把压缩后的 Blob 传给接口，实测能把图片压到原来的 20% 左右，列表加载速度提升明显。这个经验是后来才发现的，强烈建议新项目一开始就加上。

第三个是消息通知提醒。目前逾期整改的记录需要主动打开系统才能看到，如果能接入短信或企业微信通知，在隐患快到整改期限时自动提醒责任人，就能减少"忘了"导致的小隐患拖成大问题的情况。

第四个是审计日志。作为政务系统，操作留痕是硬性要求，谁在什么时候新增了一条检查记录、修改了哪个隐患的状态，都要有完整的操作日志。目前系统有基础的操作日志，但还做不到"字段级 diff"的精细程度，如果面向正式政务采购，这一步必须要加强。

6.3 给正在做类似项目的人一些建议

我在实际开发中有几点体会，是写代码之外的价值。

第一，一定要先跑现场、问用户，再写代码。这个项目前期我和几位实际使用系统的民警聊了很久，发现他们最在意的不是界面炫不炫，而是录入快不快、查数据快不快、能不能一键导出上级要的台账格式。需求沟通花的时间，最后都会在开发返工上省回来。

第二，权限设计要从第一天就确定下来，不要后面再补。管理类系统一旦数据量大、用户角色多，后补权限会导致大量页面路由、接口调用、按钮显隐逻辑的改动，牵连很广。这个项目的权限模型是开列之初就定好的，后面几乎没有为权限改过代码。

第三，联调时多用真实数据测试，不要用编造的假数据。真实数据能暴露很多边界问题，比如某个场所名称特别长、某个日期跨年、某个隐患连续整改多次未通过，这些假数据测不出来。我把派出所当年的历史台账数据导成 Excel，再转成接口返回给前端，页面一上来就发现了很多在 mock 阶段发现不了的问题。

这个项目从立项到交付大约用了两个月时间，后端 2 人，前端 1 人。回过头来看，整个过程中最值得回味的不是某个技术难点的突破，而是看着原本堆满文件的档案柜变成了电脑上轻点几下就能查完的电子台账。技术服务于业务，这句话在这个项目里体会得格外真切。