企业官网建设流程全解析

智慧城市小程序这个题目，在计算机毕设里算是被写烂了的选题，但也是被问得最多的选题。不少同学一开始冲着“源码”去找项目，结果拿到的不是缺胳膊少腿的半成品，就是版本老到连开发工具都打不开，最后还得自己从零捋需求。我前前后后帮别人改过不少类似的项目，也审过几届毕设论文，这里想把智慧城市小程序从题目拆解到具体落地的一整套思路，连同实际写代码时踩过的坑一起整理出来。如果你正准备拿这个题目做毕设，或者看了满屏源码不知道怎么下手，这篇文章应该能让你少走一大段弯路。

1. 项目定位：这题毕设到底在做什么

1.1 智慧城市选题为什么值得做

先说结论：智慧城市这个题目在毕设里经久不衰，不是因为题目新，而是因为它“大而全”，非常方便做功能扩展。一个典型的智慧城市小程序，通常可以把城市信息展示、政务办事指南、生活服务、问题反馈、地图导览、个人中心这些模块全部装进去。对毕设来说，这意味着你的系统至少具备 3 到 5 个核心功能模块，论文的“系统设计”和“功能实现”章节就有东西可写。

另外，智慧城市本身属于“政策导向性强”的选题方向，开题和答辩的时候，老师一般不会质疑这个方向没有意义。你只需要把“智慧体现在哪里”讲清楚——比如信息流整合、位置服务、反馈闭环——就能站得住脚。相比图书管理、超市收银这类传统管理系统，智慧城市小程序天然带一点物联网和城市服务的味道，做出来更像个“作品”，而不是作业。

1.2 功能边界如何从题目里拆出来

很多同学拿到“设计与实现”这种题目，第一反应是“功能越多越好”，然后把自己累死。实际上毕设源码 02497 这种编号的成品项目，功能都有明确的边界控制。以我见过的一个合格智慧城市小程序为例，核心功能一般集中在下面几条线：

• 首页信息聚合：轮播图、通知公告、城市新闻、天气展示。
• 服务分类导航：政务服务、交通出行、生活缴费、旅游文化等入口。
• 地图与周边服务：基于 SDK 的地图定位、附近公共设施查询（医院、超市、停车场等）。
• 问题上报与反馈：用户提交城市管理问题（比如井盖破损、垃圾堆积），上传图片、位置，后台查看处理状态。
• 个人中心：登录状态、我的上报记录、意见反馈、设置。

用大白话说，智慧城市小程序就是一个“城市服务的统一入口”。它不需要承担特别深度的业务逻辑，重点在于把各类服务信息聚合起来，并提供几个能体现交互闭环的功能，比如问题上报后能在“我的上报”中看到处理进度。这个闭环在答辩时非常好讲，因为它代表了系统的完整性和数据流转能力。

2. 技术选型：小程序前端和后端怎么搭

2.1 前端框架：原生还是 uniapp

这是整个项目里第一个需要拍板的技术决策。原生的微信小程序（WXML + WXSS + JS）和 uniapp 我都做过，说实话各有各的坑。原生语法学起来直观，调用微信特有的能力和 API 没有任何中间层，出 bug 的排查路径更短，适合后端出身、平时不常写前端的人。但原生的问题也很明显：代码只能在微信端跑，以后想同步到支付宝小程序或者 App 就得重写。

uniapp 胜在“一套代码多端运行”，用 Vue 语法开发，对于熟悉 Vue 的人来说上手极快。我在实际做智慧城市这类偏信息展示、表单交互的项目时，反而更推荐 uniapp。原因有两个：

• 智慧城市小程序里有大量的列表、表单、地图引用，uniapp 的组件生态能省掉很多封装工作量。
• 毕设后期如果老师要求“顺手支持 H5”，uniapp 直接发行到 H5 平台就完事，原生方案还得重新写一套页面。

不过要提醒一句，uniapp 编译到微信小程序后，部分 H5 端的 CSS 效果和 DOM 结构会有差异，比如 v-show 在某些场景下表现不稳定。所以如果选了 uniapp，一定要在项目初期就把微信开发者工具设为最终验证环境，别只盯着浏览器调试。

2.2 后端方案与数据库设计

后端这一层，我推荐用 Spring Boot 作为主体。不是说 Spring Boot 有多新，而是生态太成熟，遇到问题随便一搜就有答案，而且最稳妥的部署方式是打 jar 包放到 Linux 服务器上跑，做演示也方便。如果你对 Java 不熟，用 Node.js 的 Express 或者 Python 的 Flask 也行，但不建议用 JSP 那套老技术，答辩时一旦被追问“为什么不用前后端分离”，自己会很被动。

数据库方面，MySQL 是绝对的默认选项。智慧城市小程序的表结构其实不复杂，核心表大概有这几张：

这里值得展开讲一下 report 表。status 字段请务必设计成可扩展的字典值，比如 0 待处理、1 处理中、2 已完成、3 已驳回。很多同学图省事，直接用一个字符串存状态，后期想在“我的上报”里加筛选条件的时候就特别痛苦。另外 image_urls 字段建议用逗号分隔存多张图片的地址，或者单独建一张子表，看个人习惯。如果只是毕设演示，用逗号分隔最简单，查询时按分割处理就行。

2.3 前后端联调与接口约定

接口设计遵循一套简单的 RESTful 风格就够了，不用过度设计。统一返回体我长期用的是下面这种 JSON 结构：

{ "code": 200, "message": "success", "data": {} }

code 统一用 HTTP 语义，200 表示正常，401 表示未登录，500 表示服务端异常。data 里放实际数据。这样写的好处是前端不用在每处都做繁杂的状态判断，只要 code 不是 200，统一弹 toast 提示即可。

小程序端请求封装我用 uniapp 的 uni.request 再做一层 Promise 封装，方便统一处理带 token 的请求头。登录后把后端返回的 token 存在 uni.setStorageSync 里，后续每次请求带上。这里踩过一个坑：微信小程序真机上 require 的路径如果写错层级，请求永远报 404，排查了好半天，后来统一用绝对路径别名解决。建议你在 manifest.json 或者 vue.config.js 里配置好 @ 别名指向 src 目录，不要再写 ../../../ 这种相对路径了。

3. 核心模块拆解与实操实现

3.1 登录与身份体系

小程序的登录逻辑和网页登录完全不同。网页你输入账号密码，小程序里用户感知不到账号密码，而是通过微信的 code 换取 openid。标准流程是这样的：

1. 前端调用 wx.login 获取临时 code。
2. 后端拿着 code + appid + secret 请求微信接口，换取 openid 和 session_key。
3. 后端在 user 表里查这个 openid，没查到就自动注册一个新用户。
4. 后端生成一个 token（推荐用 JWT），返回给前端。
5. 前端把 token 存起来，后续请求带上。

代码写起来其实很直接，核心就是 uni.login 拿到 code，然后传给后端接口。我见过不少同学直接把 code 当登录凭证存在前端，这是错的，code 有效期只有五分钟，而且换取 openid 必须在后端进行，不然等于把微信密钥暴露在小程序包里。

如果你在毕设里想做“管理员后台”，建议在 user 表加一个 role 字段区分 0 普通用户和 1 管理员。管理员不需要在小程序里登录，直接做一个简单的 web 管理后台就行，这样既避免了小程序端做复杂权限控制的麻烦，也能在论文里体现后台管理的模块设计。

3.2 地图定位与周边服务

智慧城市小程序一定绕不开地图。这里不建议自己从零做地图引擎，直接用腾讯位置服务或者高德地图的微信小程序 SDK 更靠谱。我用的是腾讯位置服务，因为它和微信生态集成得最好，在微信开发者工具里可以直接用 wx.getLocation 拿坐标，再配合腾讯地图的逆地址解析，把坐标转换成城市名和具体地址。

地图相关的功能可以分为两个层次。最基础的就是 “显示当前位置”，调用 wx.getLocation 需要在小程序后台配置隐私协议和位置接口权限，这点很多第一次做的人不知道。如果不配置，真机上调用 wx.getLocation 会直接失败，开发工具里却正常，非常坑。

再往上一个层次是“附近设施查询”。比较省力的做法是，在数据库里预置一批设施点（比如学校、医院、商场）的经纬度，前端拿到用户坐标后，用勾股定理估算距离排序即可。这种做法不需要引入额外的地图检索 API，而且在答辩时可以解释为“简化了第三方依赖，同时保证了核心功能可用”。如果你想把距离算得准一点，可以用高德或腾讯的地图 Web 服务 API 做距离计算，但那是额外请求，真机上会有配额限制，不推荐。

3.3 事件上报与图片处理

上报模块是整个项目里最能体现 “用户 -> 系统 -> 数据” 流转的部分。核心流程是：用户填写问题类型、描述内容、上传图片、授权定位并自动附带地址，最后提交到后端。后端把上报记录存储后，管理员在后台能查看，处理完修改状态，用户端“我的上报”里就能看到状态变化。

图片上传这块是小程序里最容易出错的地方。微信小程序上传图片要用 wx.uploadFile，它是 multipart 表单形式上传，不是普通的 POST JSON。如果你用 uniapp，对应的 API 是 uni.uploadFile。这里有几个实际经验：

• 上传前要压缩图片，不然用户从相册选一张几 MB 的照片，上传体验极其糟糕。小程序端可以用 wx.compressImage 压缩，uniapp 里直接用 uni.compressImage。
• 服务端要限制上传大小，比如 Spring Boot 里设置 multipart 的 max-file-size 为 5MB，防止有人传大文件把你服务器打爆。
• 图片存储最简单的方式是存服务器本地磁盘，图片访问路径直接拼当前域名。如果服务器带宽不够，可以考虑压缩尺寸后存 80% 质量，视觉效果差别不大，速度却快很多。

3.4 数据可视化与后台统计

很多毕设要求里都带一句“后台统计”，实际就是给管理员提供一个数据看板。智慧城市小程序里比较适合做统计的数据有两个：上报事件的数量与状态分布、服务分类的点击量或浏览量。

我建议你在小程序端的服务分类点击时上报一条访问记录，后端按月按类型聚合，然后返回给 web 管理后台用 ECharts 画图。数据可视化不需要很花哨，一个柱状图看服务热度，一个饼图看上报状态占比，就已经能撑起论文里的“系统测试与结果分析”章节了。

如果你用的是 uniapp 开发小程序，想在同一个系统里嵌图表展示，也可以用 uCharts 这类库，但它对 canvas 的性能要求较高，真机上偶尔会有渲染卡顿。所以更稳妥的方案是 web 端做统计展示，小程序端只做数据采集和简单的个人数据列表。

4. 关键代码走读：从注册到上线

4.1 小程序端核心逻辑示例

下面这段是我在智慧城市项目里走过的小程序端登录和请求封装代码，标注了关键点，你可以直接当作骨架去改。

// utils/request.js const BASE_URL = 'https://your.domain.com/api'; function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + path, method: method, data: data, header: { 'Content-Type': 'application/json', 'token': uni.getStorageSync('token') || '' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { // token 失效，跳到登录页重新登录 uni.navigateTo({ url: '/pages/login/login' }); reject(res.data); } else { uni.showToast({ title: res.data.message, icon: 'none' }); reject(res.data); } }, fail: (err) => { uni.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); } // 登录接口 async function login() { const { code } = await uni.login(); const data = await request('/user/login', 'POST', { code }); uni.setStorageSync('token', data.token); uni.setStorageSync('userInfo', data.userInfo); }

这里的核心思路是：所有请求都经 request 封装，登录成功后 token 全局可用。真实项目中后端会对 token 做有效性校验，前端只负责透传。

4.2 后端接口实现片段

Spring Boot 端登录接口的 controller 和 service 大概是这样的：

@RestController @RequestMapping("/api/user") public class UserController { @Resource private UserService userService; @PostMapping("/login") public Result login(@RequestBody LoginDTO dto) { String token = userService.wxLogin(dto.getCode()); return Result.success(token); } }

WxLogin 这一步核心逻辑是调用微信接口换取 openid：

public String wxLogin(String code) { String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code"; String json = restTemplate.getForObject(url, String.class); JSONObject obj = JSON.parseObject(json); String openid = obj.getString("openid"); // 查数据库，不存在则新增 User user = userMapper.selectByOpenid(openid); if (user == null) { user = new User(); user.setOpenid(openid); user.setNickname("微信用户"); user.setCreateTime(new Date()); userMapper.insert(user); } // 生成 JWT return JwtUtil.createToken(user.getId(), user.getRole()); }

JWT 生成和解析用 hutool 的 JWTUtil 就行，不用手写加密逻辑。注意 JWT 密钥在配置文件中单独维护，别硬编码在代码里。

4.3 部署与发布注意点

小程序开发完，最终要正式发布到微信平台。整个流程里最容易出问题的是服务器域名配置。微信小程序要求所有请求接口必须是 HTTPS，并且域名要在小程序后台配置为合法 request 合法域名。本地开发时可以勾选开发者工具里的“不校验合法域名”，但真机预览和线上发布时绕不开这个限制。

如果你手头只有一台云服务器，建议直接用 Nginx 反向代理后端服务。Nginx 配置一个 SSL 证书（可以用免费证书），然后把 /api/ 开头的请求转发到本地的 8080 端口。这样做既解决了 HTTPS 的问题，还能顺便加一层简单的访问控制。

发布小程序版本的时候，还有一点特别容易忽略：在代码里如果写死了 http://localhost:8080 这种本地地址，真机上是完全调不通的，因为手机访问不到你的电脑。正确做法是把接口域名单独抽到一个 config.js 文件里，发布前替换成你的线上域名。我见过有同学答辩前一天还在到处找 “为什么真机上没有数据”，就是因为域名没改。

5. 避坑指南与问题排查

5.1 高频报错速查

这几类问题在开发智慧城市小程序时出现频率最高，我整理成了一张表，方便你直接对照：

5.2 设备兼容与性能优化

真机兼容性是个老话题。iPhone 的小程序会和安卓有细微差异，主要集中在这几处：

• 顶部导航栏高度不同，全面屏和刘海屏需要有安全区适配。小程序里可以用 wx.getMenuButtonBoundingClientRect 获取胶囊按钮的位置，动态计算导航栏高度。如果嫌麻烦，直接用自定义导航组件的现成方案，但要确保各平台样式统一。
• 图片懒加载。智慧城市小程序里有很多轮播图和列表缩略图，图片多的时候要加上 lazy-load 属性，避免首屏加载白屏时间太长。
• 列表数据量大的时候，用 onReachBottom 做分页加载，而不是一次性把全部数据 setData 到页面。setData 的数据量越大，性能损耗越明显，这个在小程序里尤其敏感。

另外，uniapp 项目编译到微信小程序后，建议在开发者工具里勾选 “ES6 转 ES5” 和 “上传代码时自动压缩”，这样线上包体积会小很多，代码兼容性也更好。

5.3 毕设答辩加分技巧与扩展方向

一次答辩里，老师真正关心的是“这个系统是不是你自己做出来的、有没有技术深度、有没有完整的闭环”。这里有几个实际有效的小建议：

• 在系统设计部分准备一张“业务流程时序图”，讲清楚用户从打开小程序到提交上报，再到后台处理、用户查看结果的完整数据流。纯文字描述不够直观，手画一张简图放进论文或 PPT，效果立竿见影。
• 把“异常处理”和“权限设计”单独作为一小节写，比如 token 过期自动跳登录、后台只有管理员才能访问、用户只能看自己的上报记录。这些细节是拉开分数差距的地方。
• 给项目加一个低成本但显技术的小功能，比如首页天气显示。接入和风天气或者心知天气的免费 API，返回 JSON 后萃取温度、天气状况，展示在小程序首页。代码量不大，但答辩时可以讲“系统能对接第三方开放数据，体现数据的实时性”。

如果做完整版项目时间还算宽裕，还可以考虑在后台管理界面加一个最简单的“处理状态流转”功能，即管理员点击“开始处理”，上报状态从“待处理”变成“处理中”。这个点虽然小，但能让整个系统的闭环更加立体，论文里“系统测试”部分也能多写几行真实用例。

最后说一点关于源码的看法。网上下载的毕设源码 02497 这类项目，拿到之后千万不要直接交付，第一件事是把代码里的版权信息和原作者的备注删干净，第二件事是把数据库初始数据重置成自己的测试数据。更重要的是，要能向老师讲清每一个功能的实现逻辑。源码只是起点，真正属于你自己的，是那个“你在调试中解决了一个又一个问题”的过程。