做这个项目之前我去调研过辖区派出所的举报登记流程。接待窗口放着一个厚厚的登记本民警一边听群众口述一边手写遇到电话举报就顺手记在便签纸上。一天下来几十条线索格式五花八门地址写“老菜场旁边”这种模糊位置内容里掺杂着大量私人恩怨和情绪化表达同一件事反复提交好几遍真正能立案核查的有效线索被淹没在里面。我当时就想做一个能把“无序举报”变成“结构化工单”的小系统群众打开微信就能提交后台自动过滤垃圾内容民警登录管理端就能看到按类型分好类的线索整个处理进度对举报人可见。这就是这套“小程序 PHP uniapp”举报系统的由来项目代号 ms2s2yk3。技术选型上我刻意避开了重框架——基层单位没有专职运维PHP 部署简单、出问题好排查uniapp 能一套代码同时覆盖微信小程序和 App后端接口不复杂一个人从开发到上线完全能扛住。整个项目里最有意思的部分不是前端表单也不是接口逻辑而是“敏感内容智能识别”。举报入口一打开就会有灌垃圾广告的、发不当言论的、甚至恶意举报的这类内容如果不在一开始拦住后面会耗尽民警的审核精力。这篇文章我把整个系统的需求拆解、敏感内容识别方案、前后端实现和上线遇到的坑完整记录下来。1. 从纸质登记到智能小程序举报系统的需求拆解与选型逻辑1.1 原有举报渠道的痛点在哪里我先花了三天时间摸清派出所现有的举报受理方式基本是三件事窗口登记、电话记录、社区民警微信群。窗口登记的问题在于信息结构混乱电话记录则严重依赖接听民警的归纳能力微信群更不用说60 条消息里能找出几条像样的线索全靠运气。真正让我下决心做系统的是看到了重复举报的数据。同一个楼道堆物问题两周内有 11 位居民分别通过不同渠道反映但因为记录分散接警民警以为只收到过一次反映处理优先级一直没有提上来。这不是某个人的工作态度问题是信息流转结构的问题。所以我给这个系统定的核心目标很明确把举报内容固化成结构化字段类型、时间、地点、描述、图片、联系方式自动过滤重复信息和敏感内容减少人工筛选成本让举报人能看到处理进度减少反复追问后台能按类型、状态、时间维度快速检索跟民警聊完需求之后我又把功能边界压缩了一遍。第一版不做实名认证、不做在线聊天、不做位置地图轨迹只做三件事提交举报、查询进度、后台受理办结。边界越窄项目越快落地。1.2 为什么选 PHP uniapp而不是 Java 原生小程序选型的时候我列了一下约束条件服务器是最普通的 2 核 4G 云主机预算有限维护人可能不是专职后端可能是负责信息化的小民警代码要能跑满三年以上不重构后续可能要出 App 版或者 H5 版。这几个约束一摆出来答案其实已经清楚了。PHP 在这个场景下的优势不是性能而是极低的维护门槛。ThinkPHP 或者 Laravel 的目录结构清晰出问题看日志就能定位。处理举报系统这种低频请求量的业务PHP 的并发能力绰绰有余。我曾经见过别的项目用微服务架构做这类系统最后没人维护光部署中间件就劝退了所有接手的人。uniapp 解决的是“未来可能性”的问题。微信小程序是必须做的因为群众点开即用不需要下载安装。但派出所领导经常问“能不能出个安卓版装在执法记录仪上”如果用原生小程序写后面还得重新开发。uniapp 编译到小程序的同时保留了打包 App 的能力等于花了 20% 的前期学习成本换取了未来 80% 的扩展空间。前后端通信我用的是最传统的 JSON 格式接口没有引入 WebSocket、没有用 GraphQL。举报系统是典型的“提交—审核—回执”模型请求频率低数据量小传统方案最稳。1.3 系统角色与整体流程系统分三类角色群众、值班民警、管理员。群众通过小程序提交举报系统自动做敏感内容识别命中的进入待人工复核队列通过的进入正式受理队列民警在后台看到的是已经过机器初筛的线索管理员负责账号分配和字典维护。流程用户提交举报 → 敏感内容自动识别 → 待审核列表 → 民警受理 → 办结回执 → 用户查看进度这里有一个我后来很庆幸的设计机器只做“拦截提醒”和“风险标注”不做“自动删除”。就算检测出敏感内容也只是把这张单子标记为高风险进入人工复核列表而不是直接丢弃。为什么因为用户提交的文字里如果包含“打架”“刀具”这类词它确实是敏感词但同时也是有效线索。自动删除会把真正的警情丢掉这在业务上是不能接受的。2. 敏感内容识别三件套DFA词库、图片审核API与人工兜底2.1 举报入口必须过“内容识别”这一关的原因上线第一周我就被上了一课。当时系统没有任何内容过滤机制结果后台收到了几百条垃圾信息包括广告推广、无意义刷屏、甚至辱骂民警的内容。这些垃圾内容如果不拦截民警每天光看这些就耗尽耐心了真正的举报反而被忽略。敏感内容识别在举报系统里承载三个职责过滤垃圾广告和刷屏、识别风险词汇辅助民警判断、拦截明显不实的恶意举报。这三个职责本质上是“信息降噪”——让有限的人力聚焦在真实线索上。我采用的方案是三层过滤结构第一层文本 DFA 敏感词过滤拦截明确词库命中的内容第二层云内容安全 API 审核覆盖图片和语义层面的风险第三层人工复核队列处理机器无法判断的边界情况三层过滤执行的顺序也很重要。先跑本地 DFA因为它快、免费、不消耗外部接口配额。本地 DFA 命中之后就不要再去调云 API 了省成本。本地 DFA 放行的内容再进云 API因为云 API 能识别图片中的违规元素和变体写法。2.2 DFA算法的原理与PHP实现DFADeterministic Finite Automaton确定性有限自动机是实现敏感词过滤的经典方案。它的核心思想是把敏感词库构建成前缀树遍历目标文本时逐字匹配时间复杂度是 O(n)不受词库大小影响。起初有人建议我直接用正则表达式词库里有几千个词就拼接几千个正则每次提交都跑一遍。实测下来2000 个敏感词的正则集合处理一条 500 字的举报描述需要约 300 毫秒而 DFA 只需要不到 10 毫秒。举报系统虽然请求量不高但用户端体验差异还是很大的。下面是核心实现我基于多字节字符做了优化避免中文被拆成乱码class SensitiveWordFilter { private $wordMap []; /** * 将敏感词列表构建为树形结构 */ public function addWords(array $words) { foreach ($words as $word) { $this-addWord($word); } } public function addWord($word) { $len mb_strlen($word); $map $this-wordMap; for ($i 0; $i $len; $i) { $char mb_substr($word, $i, 1); if (!isset($map[$char])) { $map[$char] []; } $map $map[$char]; } $map[end] true; } /** * 返回命中的敏感词列表 */ public function search($text) { $len mb_strlen($text); $result []; for ($i 0; $i $len; $i) { $map $this-wordMap; $matched ; for ($j $i; $j $len; $j) { $char mb_substr($text, $j, 1); if (!isset($map[$char])) { break; } $matched . $char; $map $map[$char]; if (isset($map[end])) { $result[] $matched; } } } return array_values(array_unique($result)); } }树形结构构建完成后遍历文本时每个字符只需要查询当前层级的映射关系。用“某某巷口今早有人斗殴”举例“斗殴”命中词库系统会立刻把这个词返回给上层逻辑。词库本身我用 JSON 文件维护后台管理界面提供增删改查能力。词库内容除了从公开渠道获取的基础词库之外还需要业务方持续补充——比如把本地俗称、谐音变体都加进去。我做了个简单规则单位内部每月开一次碰头会把新发现的违规表达方式录入系统。2.3 为什么还要接云内容安全API本地 DFA 能解决“精确匹配”的问题但解决不了“语义理解”的问题。用户上传一张图片里面是涉赌物品或者违规宣传单DFA 完全无能为力。用户把敏感词做变形处理比如在中间加空格、特殊符号、同音字替换DFA 也会失效。这时候就需要云服务商的内容安全 API 来兜底。我用的是腾讯云的内容安全接口文本审核和图片审核都能覆盖。接入方式不复杂一个独立服务类封装好后后端调用一次请求大概 200-500 毫秒返回结果。use TencentCloud\Common\Credential; use TencentCloud\Common\Profile\ClientProfile; use TencentCloud\Common\Profile\HttpProfile; use TencentCloud\Cms\V20190321\CmsClient; use TencentCloud\Cms\V20190321\Models\TextModerationRequest; class ContentSecurityService { private $client; public function __construct($secretId, $secretKey) { $cred new Credential($secretId, $secretKey); $httpProfile new HttpProfile(); $httpProfile-setEndpoint(cms.tencentcloudapi.com); $clientProfile new ClientProfile(); $clientProfile-setHttpProfile($httpProfile); $this-client new CmsClient($cred, ap-guangzhou, $clientProfile); } public function checkText($content) { $req new TextModerationRequest(); $params json_encode([Content base64_encode($content)]); $req-fromJsonString($params); $resp $this-client-TextModeration($req); return json_decode($resp-toJsonString(), true); } }注意这里文本内容要 base64 编码再传。返回结果里有恶意level 和风险标签我做了个映射关系命中高风险直接进人工复核队列中风险打标提醒低风险直接放行。图片审核路径也是一样的思路把用户上传的图片 URL 提交给审核接口返回结果会标注具体是哪种违规类型。我接完之后做过一批真实图片测试准确率比我预期高漏判率在可接受范围内。云内容安全 API 有一个阈值设计要点风险等级不能卡得太死也不能放得太松。我的经验是先设置一个中间阈值跑一个月根据民警实际复核的结果不断回调。前两周我们发现了很多误判——一些完全正常的举报内容被打上了风险标签原因是有用户描述里写到了赌博、治安、诈骗这类业务关键词云 API 不了解业务场景只会机械判断。后来我把业务关键词加入白名单让它们只做业务分类不做风险判定误判率明显下降。2.4 降级方案与人工兜底机器识别方案最大的隐患是第三方接口不稳定。腾讯云的内容安全接口曾经因为官方系统升级出现过十几分钟的超时那段时间如果我们的系统直接报错用户的举报就提交不上来了。我的处理方案是在调用链路上加了一个熔断开关public function checkWithFallback($content) { try { if (Cache::get(content_api_status) ! down) { $result $this-checkText($content); $this-recordLatency(); return $result; } } catch (\Exception $e) { // 连续失败3次熔断10分钟 if ($this-incrementFailCount() 3) { Cache::set(content_api_status, down, 600); } } // 降级只返回本地DFA结果标注“未经过云审核” return [ Suggestion pass, Label degraded, ]; }降级模式下本地 DFA 的结果照常使用云审核结果标记为“未审核”后台列表里强制高亮这些单子提醒民警优先人工查看。这个设计确保外部服务抖动时群众的举报入口永远不会关闭。2.5 举报人信息保护举报系统的数据敏感度很高举报人的姓名、电话、居住地址如果泄露可能会带来不可控的风险。所以我在设计数据库的时候把举报人信息和个人可识别字段单独拆出来做了加密存储。我的做法是使用 PHP 的 openssl 扩展做 AES-128-CBC 加密密钥通过环境变量注入不进代码仓库。数据库中存的都是密文只有在民警查看单子详情时才临时解密展示系统日志里不做明文记录。界面上的举报人信息列表默认只显示脱敏后的格式比如“138****1234”点击“详情”按钮才显示完整信息且这个动作会被写入审计日志。3. uniapp小程序端举报表单打磨与让人头疼的细节3.1 举报表单的设计思路前端我用 uniapp 开发编译成微信小程序。为什么不用原生微信小程序核心原因是我还要维护一个安卓 App 版本uniapp 可以一套代码编译多端不用维护两套前端。举报表单我用了最简单可靠的组件组合。事件类型用 radio-group 单选框用户只能选一个主类型——这是跟民警讨论后确定的之前设想过“多选标签”但发现用户一顿乱选反而增加后台筛选成本。单选框让用户做一次判断比让他做多项选择更不容易出错。template view classreport-form view classform-title举报信息/view radio-group changeonTypeChange label v-foritem in typeList :keyitem.value classradio-item radio :valueitem.value :checkedform.type item.value / text{{ item.label }}/text /label /radio-group textarea v-modelform.description placeholder请描述具体情况时间、地点、人物、经过 maxlength500 / view classimage-uploader view v-for(img, index) in form.images :keyindex classimage-item tappreviewImage(img) image :srcimg modeaspectFill / /view view v-ifform.images.length 4 classupload-btn tapchooseImage text/text /view /view button typeprimary tapsubmitReport提交举报/button /view /template地点字段我用了两种方式定位获取和手动填写。uniapp 里调用 uni.getLocation 获取经纬度再通过腾讯地图的逆地址解析接口转换成文字描述。但小程序需要用户在隐私弹窗里授权所以我把定位做成“选填”用户拒绝授权也能手动输入地址不能因为技术限制把不懂授权的老人挡在门外。3.2 微信登录code2session 与 token 管理举报系统不强制要求用户登录但提交之后查询进度需要绑定身份。我用的是微信一键登录用户在“我的举报”页面点击授权后自动完成登录。uni.login拿到 code 之后传给后端后端拿着 code 去微信的 code2session 接口换 openid 和 session_key再发一张自定义 token 给前端后续请求带上这个 token 即可。// uniapp 端登录逻辑 uni.login({ provider: weixin, success: async (loginRes) { const res await uni.request({ url: https://api.example.com/api/auth/login, method: POST, data: { code: loginRes.code }, }); if (res.data.code 0) { uni.setStorageSync(token, res.data.data.token); uni.setStorageSync(userInfo, res.data.data.userInfo); } }, });后端拿到前端传来的 code 后发起请求$url https://api.weixin.qq.com/sns/jscode2session . ?appid . $this-appid . secret . $this-secret . js_code . $code . grant_typeauthorization_code; $resp file_get_contents($url); $data json_decode($resp, true); // $data[openid] 存入用户表这里有个非常容易踩的坑session_key 不要直接返回给前端保存必须由后端保存。因为后续如果要解密手机号或者做其他微信能力调用都需要 session_key。把它暴露给前端就相当于把后门钥匙挂在了门口。token 我用的是自定义 token逻辑很简单uuid 用户ID 过期时间存 Redis 并设置 7 天过期。接口通过中间件读取请求头里的 Authorization 字段校验。用 PHP 的同学如果不想装 Redis也可以用数据库表存储只是每次请求多一次查询量小也能接受。3.3 图片上传与压缩举报系统的图片上传环节关系到线索审核质量但小程序端不能直接把原图传上来。一是用户手机的图片动辄 5MB 以上上传速度慢且容易失败二是服务器存储空间有限一个举报单最多 4 张图如果每张原图都全量保存一个月就是几个 GB 的存储成本。uniapp 的uni.chooseImage提供了一个sizeType参数可以指定compressed压缩图。我实测下来安卓手机的compressed图片体积大约是原图的 20%-30%堪用。但只靠系统压缩不够我建议在后端再做一次图片压缩处理PHP 里用imagejpeg重新采样将最长边压到 1280px质量参数设为 80。这样最终存储的体积能控制在 200KB 左右民警在后台查看时加载速度快也不影响辨认关键细节。public function compressImage($srcPath, $maxWidth 1280, $quality 80) { $info getimagesize($srcPath); if ($info[0] $maxWidth) { return $srcPath; } $ratio $maxWidth / $info[0]; $newWidth $maxWidth; $newHeight intval($info[1] * $ratio); $src imagecreatefromstring(file_get_contents($srcPath)); $dst imagecreatetruecolor($newWidth, $newHeight); imagecopyresampled($dst, $src, 0, 0, 0, 0, $newWidth, $newHeight, $info[0], $info[1]); $outputPath $srcPath . _compressed.jpg; imagejpeg($dst, $outputPath, $quality); imagedestroy($src); imagedestroy($dst); return $outputPath; }需要注意的是上传接口要做一个文件类型白名单校验只允许 JPG、PNG、WEBP 等常见格式并在后端重新生成文件名。曾经有朋友的项目因为没有做文件名校验被传了 PHP 脚本上去服务器直接被上传目录的 WebShell 打穿。这个坑一定不要踩。3.4 状态查询与订阅消息写完举报单之后用户最关心的就是“我举报的事情有人管吗”。我在小程序首页做了一栏“我的举报”列表展示每张单子的状态待审核、已受理、已办结。每次用户打开列表时从后端拉取最新状态不做轮询推送因为举报单的状态变化不频繁轮询反而浪费资源。真正提升体验的设计是订阅消息。用户在提交举报成功页主动勾选“处理结果通知我”小程序调用uni.requestSubscribeMessage请求一次性订阅授权后端在处理流程的状态变更节点调用微信的服务订阅消息接口推送通知。注意小程序的一次性订阅授权是“一次授权一次推送”用户提交在一个单子上授权后我只能给这一单推送一条消息。如果同一个人提交了 3 张单子需要每张都单独弹一次订阅请求。uni.requestSubscribeMessage({ tmplIds: [模板ID], success(res) { if (res[模板ID] accept) { // 用户同意授权 } }, });3.5 动态设置标题、分享与webview返回的处理做小程序的时候有几个细节很容易被忽略但在真实审核和用户体验上都能感觉到差别。第一个是动态设置标题。举报类型不同页面标题也应该跟着变。比如用户选择了“治安隐患”页面顶栏标题从“提交举报”变成“提交治安隐患线索”。我用uni.setNavigationBarTitle实现uni.setNavigationBarTitle({ title: 提交 this.currentTypeLabel 线索, });小程序审核的时候页面标题、按钮文案都必须跟实际功能保持一致。如果所有页面都叫“举报”用户和审核人员都会困惑。标题动态化之后审核也更容易通过。第二个是分享设置。有些群众看到别人举报成功会想把小程序转发给亲友但默认的小程序卡片没有上下文接收方打开并不知道要干什么。我用onShareAppMessage自定义了分享文案和路径带上前一个页面的定位参数让接收方打开直接进入当前社区的举报页。onShareAppMessage() { return { title: 我发现了一个线索来这个平台提交, path: /pages/report/index?community this.communityId, }; }第三个是 webview 返回的问题。当时我在项目里嵌了一个 webview 页面展示派出所的公开公告结果从 webview 页面返回时点击左上角返回直接退出了小程序而不是返回上一页。原因是 webview 组件的返回行为跟普通页面不一致它拦截不了工具栏的返回事件。后来我改用plus.webview管理 webview 栈在页面上自定义了一个返回浮层手动控制返回逻辑。这个在原生小程序里比较少见但用 uniapp 做混合应用时几乎必踩。4. PHP后端工单闭环登录鉴权、状态流转与接口安全4.1 接口路径规划后端我用 PHP 手写了一套轻量的 MVC 结构没有上 Laravel因为项目体量小用框架反而带来部署和性能的额外成本。当然这是我的个人选择如果你更熟悉 Laravel用它可以大幅提升开发速度。接口设计遵循 REST 风格核心就几个方法路径说明POST/api/auth/login微信登录用 code 换 tokenPOST/api/report/create提交举报单POST/api/report/upload上传举报图片GET/api/report/list我的举报列表GET/api/report/detail举报单详情GET/api/report/status举报状态查询POST/api/admin/review民警审核受理POST/api/admin/finish民警办结前端所有请求都走 HTTPS请求头带Authorization: Bearer token后端统一在入口文件里做中间件校验。写接口时我坚持一个原则返回结构统一不管成功失败都返回{ code, message, data }。这样前端只需要封装一个request函数统一处理错误码和异常弹窗代码复用率最高。4.2 数据库设计和三张核心表数据库我用 MySQL表结构力求简单。第一版只有六张表用户表、举报单表、举报图片表、审核日志表、敏感词表、系统字典表。举报单表是最核心的表字段设计如下CREATE TABLE report_record ( id int(11) unsigned NOT NULL AUTO_INCREMENT, report_no varchar(32) NOT NULL COMMENT 举报单编号, user_id int(11) NOT NULL COMMENT 举报人ID, type tinyint(4) NOT NULL COMMENT 举报类型 1治安隐患 2违法犯罪 3矛盾纠纷, location varchar(255) NOT NULL COMMENT 举报地点, longitude decimal(10,6) DEFAULT NULL COMMENT 经度, latitude decimal(10,6) DEFAULT NULL COMMENT 纬度, description text NOT NULL COMMENT 举报描述, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态 0待审核 1已受理 2已办结 3已驳回, security_label varchar(64) DEFAULT NULL COMMENT 敏感识别标签, security_level tinyint(4) DEFAULT 0 COMMENT 风险级别 0低 1中 2高, reviewer_id int(11) DEFAULT NULL COMMENT 受理民警ID, review_time datetime DEFAULT NULL COMMENT 受理时间, finish_time datetime DEFAULT NULL COMMENT 办结时间, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_status_type (status, type), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;举报单编号我用时间戳 随机数生成格式如JB2025120115300001保证可读性也方便用户打电话咨询时直接报编号。举报图片表单独拆出来是一对多关系的通用做法审核日志表记录每张单子的状态变更轨迹后面如果要出报表或者排查问题能看清全链路。关于用户表需要说明一点我没有单独建“登录账号”体系用户表直接以微信 openid 为唯一键。这个设计让用户无感登录同时因为 openid 是不可猜测的天然具有一定防伪造能力。民警端账号是单独的管理员表走用户名密码登录加验证码和登录失败锁定。4.3 敏感内容审核服务的封装策略模式把敏感内容识别逻辑封装成独立服务类是我在这个项目里很满意的一个设计决定。因为它在开发早期只依赖本地 DFA后来接了腾讯云 API再后来又可能换服务商如果这个逻辑散落在各个控制器里改起来就是一场灾难。我抽象了一个ContentSecurityService内部通过策略模式切换不同的审核提供方class ContentSecurityService { private $localFilter; private $cloudService; private $whitelist; public function __construct() { $this-localFilter new SensitiveWordFilter(); $this-cloudService new ContentSecurityService(); $this-whitelist [赌博, 治安, 诈骗, 消防]; } public function check($text, $images []) { $result [ pass true, level 0, labels [], keywords [], ]; // 第一层本地DFA $keywords $this-localFilter-search($text); foreach ($keywords as $word) { if (in_array($word, $this-whitelist)) { continue; } $result[pass] false; $result[level] max($result[level], 2); $result[labels][] 敏感词命中; $result[keywords][] $word; } // 第二层云API if ($result[pass]) { $cloudResult $this-cloudService-checkText($text); // 映射云API返回格式 if (isset($cloudResult[RiskLevel]) $cloudResult[RiskLevel] HIGH) { $result[pass] false; $result[level] 2; $result[labels][] 云识别风险; } } // 图片审核 foreach ($images as $imageUrl) { $imageResult $this-cloudService-checkImage($imageUrl); // 同样做映射和标注 } return $result; } }控制器里调用就变得非常简洁public function create(Request $request) { // 参数校验 $security $this-contentSecurity-check($request-input(description), $images); $report ReportRecord::create([ report_no $this-generateReportNo(), description $request-input(description), security_level $security[level], security_label implode(,, $security[labels]), status $security[level] 2 ? 0 : 0, ]); return json([code 0, data [report_no $report-report_no]]); }所有敏感识别结果都会被冗余存储在report_record表的security_label和security_level字段上。这样做的好处是列表页面直接查这两个字段就能做筛选不需要在查询时重新跑一遍识别逻辑。4.4 状态流转与超时提醒举报单的状态流转是整个后端业务的核心闭环。我在数据库里用status字段标记状态并约定流转规则0 待审核 → 1 已受理民警点击受理1 已受理 → 2 已办结民警填写办理结果0 待审核 → 3 已驳回审核不合格需要补充信息规则写死在服务层不通过数据库外键约束避免过度复杂。民警后台的待审核列表按照security_level倒序排列高风险单子排最前面这个排序规则是我跟实际接警民警反复确认后的方案。他们需要优先处理的是命中了敏感标签的单子因为这类单子的“有效线索概率”其实更高。还有一个细节是超时预警。我们在后台给每个状态设置了时间阈值待审核超过 24 小时没处理系统自动在管理列表里打上黄色“超时”标记超过 48 小时标记变成红色并给管理员发送告警。这个功能是用一个定时脚本实现每小时跑一次扫描状态和时间的差值。虽然业务上不是必须的但能有效防止举报单积压。4.5 接口安全签名、限流与防刷举报系统面向公众接口很容易被刷。我做了三道防护第一道是登录态校验。所有举报相关接口都必须带 token未登录的用户直接返回 401。这个校验在入口文件中统一处理避免每个控制器重复写。第二道是接口限流。用 Redis 计数器实现每个用户 ID 每小时的请求次数限制超出返回 429。比如创建举报接口限流是每小时 10 次足够正常用户使用又能有效拦住脚本批量刷单。public function checkRateLimit($userId, $action, $maxCount, $windowSeconds 3600) { $key rate_limit:{$action}:{$userId}; $current Redis::incr($key); if ($current 1) { Redis::expire($key, $windowSeconds); } if ($current $maxCount) { throw new \Exception(请求过于频繁, 429); } }第三道是基础字段校验。提交举报时description 必须有实际内容location 长度必须大于 5 个字符图片数量不超过 4 张文件类型必须是图片格式。这些校验在后端做双保险因为前端做的任何校验都能被绕过。这三道防线做完之后上线至今没遇到过恶意刷单导致服务异常的案例。5. 部署上线的真实战场备案、Nginx、基础库与兼容性5.1 小程序备案与类目选择现在的微信小程序上架必须有备案这是刚性的合规要求。备案的流程不复杂但在“备案备注信息”这个字段上很多人容易填错。我当时第一版备注写的是“开发便民服务小程序”结果被驳回了。后来我去小程序后台看了官方指引才发现备案备注需要写清楚小程序的用途和数据归属。我最终的备注信息是这样写的“本项目为某某派出所开发的群众举报线索收集平台用于收集治安隐患、违法犯罪线索等公共安全信息数据存储于本单位自建服务器。” 信息具体、用途明确很快就过审了。类目选择上这类涉及公安服务的应用最好选择“政务民生 公安”或“政务民生 便民服务”类目可能需要上传相关资质文件。我提前准备好了单位盖章的说明函避免审核来回打回。5.2 uniapp manifest 配置与基础库版本uniapp 的 manifest.json 是小程序的身份证。这里最重要的三个配置项是小程序 appid、基础库最低版本、权限接口声明。基础库版本我踩过一个坑。刚开始最低版本设得比较低为了照顾旧手机用户结果本地调试环境跑得挺好一上线就发现部分 iOS 用户页面白屏。排查了半天发现是代码里用了Promise.allSettled而当时基础库版本不支持。后来我把最低基础库版本提升到了 2.20.1覆盖了绝大多数活跃用户同时把发布代码里一些新语法用 Babel 做了降级编译。权限接口声明也要在 manifest 里提前配好。如果你用到了 uni.getLocation就要在mp-weixin的 permission 里配置:{ mp-weixin: { appid: 你的appid, setting: { urlCheck: false }, permission: { scope.userLocation: { desc: 用于获取您举报时的位置信息 } }, requiredPrivateInfos: [getLocation] } }这里提醒大家小程序官方对用户隐私接口的管控越来越严凡是涉及位置、相册、摄像头都要在后台的“用户隐私保护指引”中声明而且说明文字要让人看得懂。5.3 打包 App 时莫名多出来的权限当时为了测试拓展性我把 uniapp 代码打包成了安卓 APK结果安装时发现应用申请了麦克风权限。我的代码里根本没有用到麦克风这是哪里来的排查过程花了我小半天。最后发现原因是 uniapp 的组件库底层依赖的某个原生插件在打包时自动声明了它可能用到的一些权限即使你的业务代码没调用它权限声明也已经写进了 AndroidManifest.xml。在 manifest.json 的“App权限配置”里可以手动取消一些默认勾选的权限项取消后重新打包安装时的权限弹窗就干净了。如果打包之后出现了莫名奇妙的权限申请第一件事就是去检查 manifest.json 的 App 模块权限配置。如果你做的是纯微信小程序版本不会遇到这个问题但既然项目叫“uniapp”以后大概率要打包 App这个权限的坑提前知道能省下好几个小时的排查时间。5.4 Nginx PHP 部署中的高频问题部署环境是最普通的 CentOS Nginx PHP-FPM MySQL。这套组合网上教程很多但有几个细节经常被忽略Nginx 配置里client_max_body_size不调大的话用户上传超过 1MB 的图片会收到 413 错误。我的配置是client_max_body_size 10m因为上传接口在服务器端还会压缩10M 足够应付原图传输。PHP 的upload_max_filesize和post_max_size也要同步调大。我在多个项目里见过 Nginx 配好了但 PHP 的upload_max_filesize还是默认 2M用户一传大图就失败日志里却是 PHP 警告。伪静态配置要把前端所有的路由都指向 index.phplocation / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }还有 HTTPS 是必须的。微信小程序正式环境要求所有请求域名必须是 HTTPS并且要在小程序后台配置 request 合法域名。备案、SSL 证书部署、域名绑定这三件事要提前两个星期准备因为流程里面有等待期。5.5 上线验收的实际标准系统上线前我拿真实场景做了三轮验收测试。第一轮是功能流程测试从提交举报到民警受理、办结回执的完整链路第二轮是边界条件测试空内容提交、超长文本、恶意脚本注入、并发提交第三轮是压力测试模拟 200 个用户同时提交看接口响应和服务器负载。三轮测试中发现问题不少最典型的是恶意脚本注入。有人在前端表单里填写了scriptalert(xss)/script之类的字符串如果后端直接存库并在管理后台原样渲染就会触发 XSS 攻击。后来我在后端做了统一的输入过滤使用htmlspecialchars处理所有输出到页面的字符串同时数据库层面用预处理语句防止 SQL 注入。这两个安全习惯贯穿了整个项目。上线之后我持续观察了两周后台关于敏感内容的标注准确率、举报单平均受理时长这些指标都达到了预期。期间最让我意外的是本地 DFA 词库加进去的一些日常生活中很常见的词例如“打架”“诈骗”等带来的命中量远超我的预期这也印证了我最初的设计判断机器识别只是辅助真正做判断的还得是经过训练的民警。这个项目做完之后最大的体会是这类公共安全类的小系统代码写得“聪明”不如写得“清楚”功能做得“多”不如做得“闭环”。哪怕只是一个简单的状态流转只要每一步都有记录、有回执、有兜底用户和民警都能感到系统确实在解决问题。
做这个项目之前我去调研过辖区派出所的举报登记流程。接待窗口放着一个厚厚的登记本民警一边听群众口述一边手写遇到电话举报就顺手记在便签纸上。一天下来几十条线索格式五花八门地址写“老菜场旁边”这种模糊位置内容里掺杂着大量私人恩怨和情绪化表达同一件事反复提交好几遍真正能立案核查的有效线索被淹没在里面。我当时就想做一个能把“无序举报”变成“结构化工单”的小系统群众打开微信就能提交后台自动过滤垃圾内容民警登录管理端就能看到按类型分好类的线索整个处理进度对举报人可见。这就是这套“小程序 PHP uniapp”举报系统的由来项目代号 ms2s2yk3。技术选型上我刻意避开了重框架——基层单位没有专职运维PHP 部署简单、出问题好排查uniapp 能一套代码同时覆盖微信小程序和 App后端接口不复杂一个人从开发到上线完全能扛住。整个项目里最有意思的部分不是前端表单也不是接口逻辑而是“敏感内容智能识别”。举报入口一打开就会有灌垃圾广告的、发不当言论的、甚至恶意举报的这类内容如果不在一开始拦住后面会耗尽民警的审核精力。这篇文章我把整个系统的需求拆解、敏感内容识别方案、前后端实现和上线遇到的坑完整记录下来。1. 从纸质登记到智能小程序举报系统的需求拆解与选型逻辑1.1 原有举报渠道的痛点在哪里我先花了三天时间摸清派出所现有的举报受理方式基本是三件事窗口登记、电话记录、社区民警微信群。窗口登记的问题在于信息结构混乱电话记录则严重依赖接听民警的归纳能力微信群更不用说60 条消息里能找出几条像样的线索全靠运气。真正让我下决心做系统的是看到了重复举报的数据。同一个楼道堆物问题两周内有 11 位居民分别通过不同渠道反映但因为记录分散接警民警以为只收到过一次反映处理优先级一直没有提上来。这不是某个人的工作态度问题是信息流转结构的问题。所以我给这个系统定的核心目标很明确把举报内容固化成结构化字段类型、时间、地点、描述、图片、联系方式自动过滤重复信息和敏感内容减少人工筛选成本让举报人能看到处理进度减少反复追问后台能按类型、状态、时间维度快速检索跟民警聊完需求之后我又把功能边界压缩了一遍。第一版不做实名认证、不做在线聊天、不做位置地图轨迹只做三件事提交举报、查询进度、后台受理办结。边界越窄项目越快落地。1.2 为什么选 PHP uniapp而不是 Java 原生小程序选型的时候我列了一下约束条件服务器是最普通的 2 核 4G 云主机预算有限维护人可能不是专职后端可能是负责信息化的小民警代码要能跑满三年以上不重构后续可能要出 App 版或者 H5 版。这几个约束一摆出来答案其实已经清楚了。PHP 在这个场景下的优势不是性能而是极低的维护门槛。ThinkPHP 或者 Laravel 的目录结构清晰出问题看日志就能定位。处理举报系统这种低频请求量的业务PHP 的并发能力绰绰有余。我曾经见过别的项目用微服务架构做这类系统最后没人维护光部署中间件就劝退了所有接手的人。uniapp 解决的是“未来可能性”的问题。微信小程序是必须做的因为群众点开即用不需要下载安装。但派出所领导经常问“能不能出个安卓版装在执法记录仪上”如果用原生小程序写后面还得重新开发。uniapp 编译到小程序的同时保留了打包 App 的能力等于花了 20% 的前期学习成本换取了未来 80% 的扩展空间。前后端通信我用的是最传统的 JSON 格式接口没有引入 WebSocket、没有用 GraphQL。举报系统是典型的“提交—审核—回执”模型请求频率低数据量小传统方案最稳。1.3 系统角色与整体流程系统分三类角色群众、值班民警、管理员。群众通过小程序提交举报系统自动做敏感内容识别命中的进入待人工复核队列通过的进入正式受理队列民警在后台看到的是已经过机器初筛的线索管理员负责账号分配和字典维护。流程用户提交举报 → 敏感内容自动识别 → 待审核列表 → 民警受理 → 办结回执 → 用户查看进度这里有一个我后来很庆幸的设计机器只做“拦截提醒”和“风险标注”不做“自动删除”。就算检测出敏感内容也只是把这张单子标记为高风险进入人工复核列表而不是直接丢弃。为什么因为用户提交的文字里如果包含“打架”“刀具”这类词它确实是敏感词但同时也是有效线索。自动删除会把真正的警情丢掉这在业务上是不能接受的。2. 敏感内容识别三件套DFA词库、图片审核API与人工兜底2.1 举报入口必须过“内容识别”这一关的原因上线第一周我就被上了一课。当时系统没有任何内容过滤机制结果后台收到了几百条垃圾信息包括广告推广、无意义刷屏、甚至辱骂民警的内容。这些垃圾内容如果不拦截民警每天光看这些就耗尽耐心了真正的举报反而被忽略。敏感内容识别在举报系统里承载三个职责过滤垃圾广告和刷屏、识别风险词汇辅助民警判断、拦截明显不实的恶意举报。这三个职责本质上是“信息降噪”——让有限的人力聚焦在真实线索上。我采用的方案是三层过滤结构第一层文本 DFA 敏感词过滤拦截明确词库命中的内容第二层云内容安全 API 审核覆盖图片和语义层面的风险第三层人工复核队列处理机器无法判断的边界情况三层过滤执行的顺序也很重要。先跑本地 DFA因为它快、免费、不消耗外部接口配额。本地 DFA 命中之后就不要再去调云 API 了省成本。本地 DFA 放行的内容再进云 API因为云 API 能识别图片中的违规元素和变体写法。2.2 DFA算法的原理与PHP实现DFADeterministic Finite Automaton确定性有限自动机是实现敏感词过滤的经典方案。它的核心思想是把敏感词库构建成前缀树遍历目标文本时逐字匹配时间复杂度是 O(n)不受词库大小影响。起初有人建议我直接用正则表达式词库里有几千个词就拼接几千个正则每次提交都跑一遍。实测下来2000 个敏感词的正则集合处理一条 500 字的举报描述需要约 300 毫秒而 DFA 只需要不到 10 毫秒。举报系统虽然请求量不高但用户端体验差异还是很大的。下面是核心实现我基于多字节字符做了优化避免中文被拆成乱码class SensitiveWordFilter { private $wordMap []; /** * 将敏感词列表构建为树形结构 */ public function addWords(array $words) { foreach ($words as $word) { $this-addWord($word); } } public function addWord($word) { $len mb_strlen($word); $map $this-wordMap; for ($i 0; $i $len; $i) { $char mb_substr($word, $i, 1); if (!isset($map[$char])) { $map[$char] []; } $map $map[$char]; } $map[end] true; } /** * 返回命中的敏感词列表 */ public function search($text) { $len mb_strlen($text); $result []; for ($i 0; $i $len; $i) { $map $this-wordMap; $matched ; for ($j $i; $j $len; $j) { $char mb_substr($text, $j, 1); if (!isset($map[$char])) { break; } $matched . $char; $map $map[$char]; if (isset($map[end])) { $result[] $matched; } } } return array_values(array_unique($result)); } }树形结构构建完成后遍历文本时每个字符只需要查询当前层级的映射关系。用“某某巷口今早有人斗殴”举例“斗殴”命中词库系统会立刻把这个词返回给上层逻辑。词库本身我用 JSON 文件维护后台管理界面提供增删改查能力。词库内容除了从公开渠道获取的基础词库之外还需要业务方持续补充——比如把本地俗称、谐音变体都加进去。我做了个简单规则单位内部每月开一次碰头会把新发现的违规表达方式录入系统。2.3 为什么还要接云内容安全API本地 DFA 能解决“精确匹配”的问题但解决不了“语义理解”的问题。用户上传一张图片里面是涉赌物品或者违规宣传单DFA 完全无能为力。用户把敏感词做变形处理比如在中间加空格、特殊符号、同音字替换DFA 也会失效。这时候就需要云服务商的内容安全 API 来兜底。我用的是腾讯云的内容安全接口文本审核和图片审核都能覆盖。接入方式不复杂一个独立服务类封装好后后端调用一次请求大概 200-500 毫秒返回结果。use TencentCloud\Common\Credential; use TencentCloud\Common\Profile\ClientProfile; use TencentCloud\Common\Profile\HttpProfile; use TencentCloud\Cms\V20190321\CmsClient; use TencentCloud\Cms\V20190321\Models\TextModerationRequest; class ContentSecurityService { private $client; public function __construct($secretId, $secretKey) { $cred new Credential($secretId, $secretKey); $httpProfile new HttpProfile(); $httpProfile-setEndpoint(cms.tencentcloudapi.com); $clientProfile new ClientProfile(); $clientProfile-setHttpProfile($httpProfile); $this-client new CmsClient($cred, ap-guangzhou, $clientProfile); } public function checkText($content) { $req new TextModerationRequest(); $params json_encode([Content base64_encode($content)]); $req-fromJsonString($params); $resp $this-client-TextModeration($req); return json_decode($resp-toJsonString(), true); } }注意这里文本内容要 base64 编码再传。返回结果里有恶意level 和风险标签我做了个映射关系命中高风险直接进人工复核队列中风险打标提醒低风险直接放行。图片审核路径也是一样的思路把用户上传的图片 URL 提交给审核接口返回结果会标注具体是哪种违规类型。我接完之后做过一批真实图片测试准确率比我预期高漏判率在可接受范围内。云内容安全 API 有一个阈值设计要点风险等级不能卡得太死也不能放得太松。我的经验是先设置一个中间阈值跑一个月根据民警实际复核的结果不断回调。前两周我们发现了很多误判——一些完全正常的举报内容被打上了风险标签原因是有用户描述里写到了赌博、治安、诈骗这类业务关键词云 API 不了解业务场景只会机械判断。后来我把业务关键词加入白名单让它们只做业务分类不做风险判定误判率明显下降。2.4 降级方案与人工兜底机器识别方案最大的隐患是第三方接口不稳定。腾讯云的内容安全接口曾经因为官方系统升级出现过十几分钟的超时那段时间如果我们的系统直接报错用户的举报就提交不上来了。我的处理方案是在调用链路上加了一个熔断开关public function checkWithFallback($content) { try { if (Cache::get(content_api_status) ! down) { $result $this-checkText($content); $this-recordLatency(); return $result; } } catch (\Exception $e) { // 连续失败3次熔断10分钟 if ($this-incrementFailCount() 3) { Cache::set(content_api_status, down, 600); } } // 降级只返回本地DFA结果标注“未经过云审核” return [ Suggestion pass, Label degraded, ]; }降级模式下本地 DFA 的结果照常使用云审核结果标记为“未审核”后台列表里强制高亮这些单子提醒民警优先人工查看。这个设计确保外部服务抖动时群众的举报入口永远不会关闭。2.5 举报人信息保护举报系统的数据敏感度很高举报人的姓名、电话、居住地址如果泄露可能会带来不可控的风险。所以我在设计数据库的时候把举报人信息和个人可识别字段单独拆出来做了加密存储。我的做法是使用 PHP 的 openssl 扩展做 AES-128-CBC 加密密钥通过环境变量注入不进代码仓库。数据库中存的都是密文只有在民警查看单子详情时才临时解密展示系统日志里不做明文记录。界面上的举报人信息列表默认只显示脱敏后的格式比如“138****1234”点击“详情”按钮才显示完整信息且这个动作会被写入审计日志。3. uniapp小程序端举报表单打磨与让人头疼的细节3.1 举报表单的设计思路前端我用 uniapp 开发编译成微信小程序。为什么不用原生微信小程序核心原因是我还要维护一个安卓 App 版本uniapp 可以一套代码编译多端不用维护两套前端。举报表单我用了最简单可靠的组件组合。事件类型用 radio-group 单选框用户只能选一个主类型——这是跟民警讨论后确定的之前设想过“多选标签”但发现用户一顿乱选反而增加后台筛选成本。单选框让用户做一次判断比让他做多项选择更不容易出错。template view classreport-form view classform-title举报信息/view radio-group changeonTypeChange label v-foritem in typeList :keyitem.value classradio-item radio :valueitem.value :checkedform.type item.value / text{{ item.label }}/text /label /radio-group textarea v-modelform.description placeholder请描述具体情况时间、地点、人物、经过 maxlength500 / view classimage-uploader view v-for(img, index) in form.images :keyindex classimage-item tappreviewImage(img) image :srcimg modeaspectFill / /view view v-ifform.images.length 4 classupload-btn tapchooseImage text/text /view /view button typeprimary tapsubmitReport提交举报/button /view /template地点字段我用了两种方式定位获取和手动填写。uniapp 里调用 uni.getLocation 获取经纬度再通过腾讯地图的逆地址解析接口转换成文字描述。但小程序需要用户在隐私弹窗里授权所以我把定位做成“选填”用户拒绝授权也能手动输入地址不能因为技术限制把不懂授权的老人挡在门外。3.2 微信登录code2session 与 token 管理举报系统不强制要求用户登录但提交之后查询进度需要绑定身份。我用的是微信一键登录用户在“我的举报”页面点击授权后自动完成登录。uni.login拿到 code 之后传给后端后端拿着 code 去微信的 code2session 接口换 openid 和 session_key再发一张自定义 token 给前端后续请求带上这个 token 即可。// uniapp 端登录逻辑 uni.login({ provider: weixin, success: async (loginRes) { const res await uni.request({ url: https://api.example.com/api/auth/login, method: POST, data: { code: loginRes.code }, }); if (res.data.code 0) { uni.setStorageSync(token, res.data.data.token); uni.setStorageSync(userInfo, res.data.data.userInfo); } }, });后端拿到前端传来的 code 后发起请求$url https://api.weixin.qq.com/sns/jscode2session . ?appid . $this-appid . secret . $this-secret . js_code . $code . grant_typeauthorization_code; $resp file_get_contents($url); $data json_decode($resp, true); // $data[openid] 存入用户表这里有个非常容易踩的坑session_key 不要直接返回给前端保存必须由后端保存。因为后续如果要解密手机号或者做其他微信能力调用都需要 session_key。把它暴露给前端就相当于把后门钥匙挂在了门口。token 我用的是自定义 token逻辑很简单uuid 用户ID 过期时间存 Redis 并设置 7 天过期。接口通过中间件读取请求头里的 Authorization 字段校验。用 PHP 的同学如果不想装 Redis也可以用数据库表存储只是每次请求多一次查询量小也能接受。3.3 图片上传与压缩举报系统的图片上传环节关系到线索审核质量但小程序端不能直接把原图传上来。一是用户手机的图片动辄 5MB 以上上传速度慢且容易失败二是服务器存储空间有限一个举报单最多 4 张图如果每张原图都全量保存一个月就是几个 GB 的存储成本。uniapp 的uni.chooseImage提供了一个sizeType参数可以指定compressed压缩图。我实测下来安卓手机的compressed图片体积大约是原图的 20%-30%堪用。但只靠系统压缩不够我建议在后端再做一次图片压缩处理PHP 里用imagejpeg重新采样将最长边压到 1280px质量参数设为 80。这样最终存储的体积能控制在 200KB 左右民警在后台查看时加载速度快也不影响辨认关键细节。public function compressImage($srcPath, $maxWidth 1280, $quality 80) { $info getimagesize($srcPath); if ($info[0] $maxWidth) { return $srcPath; } $ratio $maxWidth / $info[0]; $newWidth $maxWidth; $newHeight intval($info[1] * $ratio); $src imagecreatefromstring(file_get_contents($srcPath)); $dst imagecreatetruecolor($newWidth, $newHeight); imagecopyresampled($dst, $src, 0, 0, 0, 0, $newWidth, $newHeight, $info[0], $info[1]); $outputPath $srcPath . _compressed.jpg; imagejpeg($dst, $outputPath, $quality); imagedestroy($src); imagedestroy($dst); return $outputPath; }需要注意的是上传接口要做一个文件类型白名单校验只允许 JPG、PNG、WEBP 等常见格式并在后端重新生成文件名。曾经有朋友的项目因为没有做文件名校验被传了 PHP 脚本上去服务器直接被上传目录的 WebShell 打穿。这个坑一定不要踩。3.4 状态查询与订阅消息写完举报单之后用户最关心的就是“我举报的事情有人管吗”。我在小程序首页做了一栏“我的举报”列表展示每张单子的状态待审核、已受理、已办结。每次用户打开列表时从后端拉取最新状态不做轮询推送因为举报单的状态变化不频繁轮询反而浪费资源。真正提升体验的设计是订阅消息。用户在提交举报成功页主动勾选“处理结果通知我”小程序调用uni.requestSubscribeMessage请求一次性订阅授权后端在处理流程的状态变更节点调用微信的服务订阅消息接口推送通知。注意小程序的一次性订阅授权是“一次授权一次推送”用户提交在一个单子上授权后我只能给这一单推送一条消息。如果同一个人提交了 3 张单子需要每张都单独弹一次订阅请求。uni.requestSubscribeMessage({ tmplIds: [模板ID], success(res) { if (res[模板ID] accept) { // 用户同意授权 } }, });3.5 动态设置标题、分享与webview返回的处理做小程序的时候有几个细节很容易被忽略但在真实审核和用户体验上都能感觉到差别。第一个是动态设置标题。举报类型不同页面标题也应该跟着变。比如用户选择了“治安隐患”页面顶栏标题从“提交举报”变成“提交治安隐患线索”。我用uni.setNavigationBarTitle实现uni.setNavigationBarTitle({ title: 提交 this.currentTypeLabel 线索, });小程序审核的时候页面标题、按钮文案都必须跟实际功能保持一致。如果所有页面都叫“举报”用户和审核人员都会困惑。标题动态化之后审核也更容易通过。第二个是分享设置。有些群众看到别人举报成功会想把小程序转发给亲友但默认的小程序卡片没有上下文接收方打开并不知道要干什么。我用onShareAppMessage自定义了分享文案和路径带上前一个页面的定位参数让接收方打开直接进入当前社区的举报页。onShareAppMessage() { return { title: 我发现了一个线索来这个平台提交, path: /pages/report/index?community this.communityId, }; }第三个是 webview 返回的问题。当时我在项目里嵌了一个 webview 页面展示派出所的公开公告结果从 webview 页面返回时点击左上角返回直接退出了小程序而不是返回上一页。原因是 webview 组件的返回行为跟普通页面不一致它拦截不了工具栏的返回事件。后来我改用plus.webview管理 webview 栈在页面上自定义了一个返回浮层手动控制返回逻辑。这个在原生小程序里比较少见但用 uniapp 做混合应用时几乎必踩。4. PHP后端工单闭环登录鉴权、状态流转与接口安全4.1 接口路径规划后端我用 PHP 手写了一套轻量的 MVC 结构没有上 Laravel因为项目体量小用框架反而带来部署和性能的额外成本。当然这是我的个人选择如果你更熟悉 Laravel用它可以大幅提升开发速度。接口设计遵循 REST 风格核心就几个方法路径说明POST/api/auth/login微信登录用 code 换 tokenPOST/api/report/create提交举报单POST/api/report/upload上传举报图片GET/api/report/list我的举报列表GET/api/report/detail举报单详情GET/api/report/status举报状态查询POST/api/admin/review民警审核受理POST/api/admin/finish民警办结前端所有请求都走 HTTPS请求头带Authorization: Bearer token后端统一在入口文件里做中间件校验。写接口时我坚持一个原则返回结构统一不管成功失败都返回{ code, message, data }。这样前端只需要封装一个request函数统一处理错误码和异常弹窗代码复用率最高。4.2 数据库设计和三张核心表数据库我用 MySQL表结构力求简单。第一版只有六张表用户表、举报单表、举报图片表、审核日志表、敏感词表、系统字典表。举报单表是最核心的表字段设计如下CREATE TABLE report_record ( id int(11) unsigned NOT NULL AUTO_INCREMENT, report_no varchar(32) NOT NULL COMMENT 举报单编号, user_id int(11) NOT NULL COMMENT 举报人ID, type tinyint(4) NOT NULL COMMENT 举报类型 1治安隐患 2违法犯罪 3矛盾纠纷, location varchar(255) NOT NULL COMMENT 举报地点, longitude decimal(10,6) DEFAULT NULL COMMENT 经度, latitude decimal(10,6) DEFAULT NULL COMMENT 纬度, description text NOT NULL COMMENT 举报描述, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态 0待审核 1已受理 2已办结 3已驳回, security_label varchar(64) DEFAULT NULL COMMENT 敏感识别标签, security_level tinyint(4) DEFAULT 0 COMMENT 风险级别 0低 1中 2高, reviewer_id int(11) DEFAULT NULL COMMENT 受理民警ID, review_time datetime DEFAULT NULL COMMENT 受理时间, finish_time datetime DEFAULT NULL COMMENT 办结时间, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_status_type (status, type), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;举报单编号我用时间戳 随机数生成格式如JB2025120115300001保证可读性也方便用户打电话咨询时直接报编号。举报图片表单独拆出来是一对多关系的通用做法审核日志表记录每张单子的状态变更轨迹后面如果要出报表或者排查问题能看清全链路。关于用户表需要说明一点我没有单独建“登录账号”体系用户表直接以微信 openid 为唯一键。这个设计让用户无感登录同时因为 openid 是不可猜测的天然具有一定防伪造能力。民警端账号是单独的管理员表走用户名密码登录加验证码和登录失败锁定。4.3 敏感内容审核服务的封装策略模式把敏感内容识别逻辑封装成独立服务类是我在这个项目里很满意的一个设计决定。因为它在开发早期只依赖本地 DFA后来接了腾讯云 API再后来又可能换服务商如果这个逻辑散落在各个控制器里改起来就是一场灾难。我抽象了一个ContentSecurityService内部通过策略模式切换不同的审核提供方class ContentSecurityService { private $localFilter; private $cloudService; private $whitelist; public function __construct() { $this-localFilter new SensitiveWordFilter(); $this-cloudService new ContentSecurityService(); $this-whitelist [赌博, 治安, 诈骗, 消防]; } public function check($text, $images []) { $result [ pass true, level 0, labels [], keywords [], ]; // 第一层本地DFA $keywords $this-localFilter-search($text); foreach ($keywords as $word) { if (in_array($word, $this-whitelist)) { continue; } $result[pass] false; $result[level] max($result[level], 2); $result[labels][] 敏感词命中; $result[keywords][] $word; } // 第二层云API if ($result[pass]) { $cloudResult $this-cloudService-checkText($text); // 映射云API返回格式 if (isset($cloudResult[RiskLevel]) $cloudResult[RiskLevel] HIGH) { $result[pass] false; $result[level] 2; $result[labels][] 云识别风险; } } // 图片审核 foreach ($images as $imageUrl) { $imageResult $this-cloudService-checkImage($imageUrl); // 同样做映射和标注 } return $result; } }控制器里调用就变得非常简洁public function create(Request $request) { // 参数校验 $security $this-contentSecurity-check($request-input(description), $images); $report ReportRecord::create([ report_no $this-generateReportNo(), description $request-input(description), security_level $security[level], security_label implode(,, $security[labels]), status $security[level] 2 ? 0 : 0, ]); return json([code 0, data [report_no $report-report_no]]); }所有敏感识别结果都会被冗余存储在report_record表的security_label和security_level字段上。这样做的好处是列表页面直接查这两个字段就能做筛选不需要在查询时重新跑一遍识别逻辑。4.4 状态流转与超时提醒举报单的状态流转是整个后端业务的核心闭环。我在数据库里用status字段标记状态并约定流转规则0 待审核 → 1 已受理民警点击受理1 已受理 → 2 已办结民警填写办理结果0 待审核 → 3 已驳回审核不合格需要补充信息规则写死在服务层不通过数据库外键约束避免过度复杂。民警后台的待审核列表按照security_level倒序排列高风险单子排最前面这个排序规则是我跟实际接警民警反复确认后的方案。他们需要优先处理的是命中了敏感标签的单子因为这类单子的“有效线索概率”其实更高。还有一个细节是超时预警。我们在后台给每个状态设置了时间阈值待审核超过 24 小时没处理系统自动在管理列表里打上黄色“超时”标记超过 48 小时标记变成红色并给管理员发送告警。这个功能是用一个定时脚本实现每小时跑一次扫描状态和时间的差值。虽然业务上不是必须的但能有效防止举报单积压。4.5 接口安全签名、限流与防刷举报系统面向公众接口很容易被刷。我做了三道防护第一道是登录态校验。所有举报相关接口都必须带 token未登录的用户直接返回 401。这个校验在入口文件中统一处理避免每个控制器重复写。第二道是接口限流。用 Redis 计数器实现每个用户 ID 每小时的请求次数限制超出返回 429。比如创建举报接口限流是每小时 10 次足够正常用户使用又能有效拦住脚本批量刷单。public function checkRateLimit($userId, $action, $maxCount, $windowSeconds 3600) { $key rate_limit:{$action}:{$userId}; $current Redis::incr($key); if ($current 1) { Redis::expire($key, $windowSeconds); } if ($current $maxCount) { throw new \Exception(请求过于频繁, 429); } }第三道是基础字段校验。提交举报时description 必须有实际内容location 长度必须大于 5 个字符图片数量不超过 4 张文件类型必须是图片格式。这些校验在后端做双保险因为前端做的任何校验都能被绕过。这三道防线做完之后上线至今没遇到过恶意刷单导致服务异常的案例。5. 部署上线的真实战场备案、Nginx、基础库与兼容性5.1 小程序备案与类目选择现在的微信小程序上架必须有备案这是刚性的合规要求。备案的流程不复杂但在“备案备注信息”这个字段上很多人容易填错。我当时第一版备注写的是“开发便民服务小程序”结果被驳回了。后来我去小程序后台看了官方指引才发现备案备注需要写清楚小程序的用途和数据归属。我最终的备注信息是这样写的“本项目为某某派出所开发的群众举报线索收集平台用于收集治安隐患、违法犯罪线索等公共安全信息数据存储于本单位自建服务器。” 信息具体、用途明确很快就过审了。类目选择上这类涉及公安服务的应用最好选择“政务民生 公安”或“政务民生 便民服务”类目可能需要上传相关资质文件。我提前准备好了单位盖章的说明函避免审核来回打回。5.2 uniapp manifest 配置与基础库版本uniapp 的 manifest.json 是小程序的身份证。这里最重要的三个配置项是小程序 appid、基础库最低版本、权限接口声明。基础库版本我踩过一个坑。刚开始最低版本设得比较低为了照顾旧手机用户结果本地调试环境跑得挺好一上线就发现部分 iOS 用户页面白屏。排查了半天发现是代码里用了Promise.allSettled而当时基础库版本不支持。后来我把最低基础库版本提升到了 2.20.1覆盖了绝大多数活跃用户同时把发布代码里一些新语法用 Babel 做了降级编译。权限接口声明也要在 manifest 里提前配好。如果你用到了 uni.getLocation就要在mp-weixin的 permission 里配置:{ mp-weixin: { appid: 你的appid, setting: { urlCheck: false }, permission: { scope.userLocation: { desc: 用于获取您举报时的位置信息 } }, requiredPrivateInfos: [getLocation] } }这里提醒大家小程序官方对用户隐私接口的管控越来越严凡是涉及位置、相册、摄像头都要在后台的“用户隐私保护指引”中声明而且说明文字要让人看得懂。5.3 打包 App 时莫名多出来的权限当时为了测试拓展性我把 uniapp 代码打包成了安卓 APK结果安装时发现应用申请了麦克风权限。我的代码里根本没有用到麦克风这是哪里来的排查过程花了我小半天。最后发现原因是 uniapp 的组件库底层依赖的某个原生插件在打包时自动声明了它可能用到的一些权限即使你的业务代码没调用它权限声明也已经写进了 AndroidManifest.xml。在 manifest.json 的“App权限配置”里可以手动取消一些默认勾选的权限项取消后重新打包安装时的权限弹窗就干净了。如果打包之后出现了莫名奇妙的权限申请第一件事就是去检查 manifest.json 的 App 模块权限配置。如果你做的是纯微信小程序版本不会遇到这个问题但既然项目叫“uniapp”以后大概率要打包 App这个权限的坑提前知道能省下好几个小时的排查时间。5.4 Nginx PHP 部署中的高频问题部署环境是最普通的 CentOS Nginx PHP-FPM MySQL。这套组合网上教程很多但有几个细节经常被忽略Nginx 配置里client_max_body_size不调大的话用户上传超过 1MB 的图片会收到 413 错误。我的配置是client_max_body_size 10m因为上传接口在服务器端还会压缩10M 足够应付原图传输。PHP 的upload_max_filesize和post_max_size也要同步调大。我在多个项目里见过 Nginx 配好了但 PHP 的upload_max_filesize还是默认 2M用户一传大图就失败日志里却是 PHP 警告。伪静态配置要把前端所有的路由都指向 index.phplocation / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }还有 HTTPS 是必须的。微信小程序正式环境要求所有请求域名必须是 HTTPS并且要在小程序后台配置 request 合法域名。备案、SSL 证书部署、域名绑定这三件事要提前两个星期准备因为流程里面有等待期。5.5 上线验收的实际标准系统上线前我拿真实场景做了三轮验收测试。第一轮是功能流程测试从提交举报到民警受理、办结回执的完整链路第二轮是边界条件测试空内容提交、超长文本、恶意脚本注入、并发提交第三轮是压力测试模拟 200 个用户同时提交看接口响应和服务器负载。三轮测试中发现问题不少最典型的是恶意脚本注入。有人在前端表单里填写了scriptalert(xss)/script之类的字符串如果后端直接存库并在管理后台原样渲染就会触发 XSS 攻击。后来我在后端做了统一的输入过滤使用htmlspecialchars处理所有输出到页面的字符串同时数据库层面用预处理语句防止 SQL 注入。这两个安全习惯贯穿了整个项目。上线之后我持续观察了两周后台关于敏感内容的标注准确率、举报单平均受理时长这些指标都达到了预期。期间最让我意外的是本地 DFA 词库加进去的一些日常生活中很常见的词例如“打架”“诈骗”等带来的命中量远超我的预期这也印证了我最初的设计判断机器识别只是辅助真正做判断的还得是经过训练的民警。这个项目做完之后最大的体会是这类公共安全类的小系统代码写得“聪明”不如写得“清楚”功能做得“多”不如做得“闭环”。哪怕只是一个简单的状态流转只要每一步都有记录、有回执、有兜底用户和民警都能感到系统确实在解决问题。
