1. 一年的迭代路线图：调问到底在解决什么问题
先交代一下背景。调问是一套开源的问卷系统，从立项开始就定位在“让问卷这件事可控、可扩展、可私有化”这个方向上。过去一年，它从 3.0 一路迭代到 3.5，中间打了大小十多个版本，核心变化集中在题型引擎、逻辑编排、数据回收、部署体验和开源治理这几条线上。如果你正在选型问卷系统，或者自己维护着类似的开源项目，这篇汇总应该能帮你省不少排查问题的时间。
很多人问过我，问卷系统看起来不是很简单吗？不就是题目加选项，用户填完提交，后台看数据？实际做起来完全不是这么回事。企业内部做调研，问卷可能要挂十几套逻辑：某个选项选了“不满意”，后面连续五道题都不显示；部门不同，看到的题目组不同；甚至同一个问卷发给不同人群，题目顺序都要随机打乱。高校和科研团队的需求更细，要支持矩阵题、量表题、量表计分，还要把原始答卷导出成 SPSS 能直接读的格式。线下活动扫码填问卷，网络波动大，页面动不动就白屏，这又是另一类问题。
所以调问这一年的迭代，不是在堆功能，而是在解决这四件最实际的事：第一，题型能不能像搭积木一样自由组合；第二，题目之间的逻辑关系能不能可视化编排；第三，数据收上来之后能不能实时变成结论而不是让人去导出 Excel 手工透视；第四，部署和二次开发的门槛能不能低到让一个普通运维也能独立搞定。下面我按迭代主线一条一条说。
1.1 问卷系统的真正痛点
先说痛点，因为不搞清楚痛点，后面所有功能点都会看得莫名其妙。问卷系统在真实使用中，最容易暴露问题的往往不是“填问卷”这个动作本身，而是“设计问卷”和“处理数据”这两个环节。
设计问卷时，业务方最常提的需求是：题型要多。除了单选、多选、填空，还有矩阵单选项、矩阵多选项、排序题、打分题、NPS 推荐值、滑块题、签名题、图片上传题、地址选择、日期时间、录音上传，甚至要自定义 html。如果你用传统表单框架去实现，每加一种题型就要写一套模板加一套后端解析逻辑，维护成本成倍上涨。
逻辑控制是第二个大坑。真实问卷里“按条件显示题目”是标配，但条件维度五花八门：按上一题选项跳转、按用户角色过滤、按答卷次数配额、按随机分组控制题目顺序。这里面最容易翻车的是“选项级关联”——比如选了“其他”之后必须弹出一个填空框，这个逻辑如果在后端处理，接口要判断无数次；如果在前端处理，页面状态管理又容易写成一团乱麻。
数据阶段的问题更隐蔽。问卷回收量一旦上千，传统的“下载 Excel 看表”模式就撑不住了。市场部希望看到实时回收率，HR 希望按部门交叉分析满意度均值，科研团队要求能过滤掉答题时间低于 30 秒的废卷，还要把多选题的选项展开成二值化的 0/1 矩阵。这些要求叠在一起，就倒逼问卷系统必须有一个统计层，而不是简单的报表层。
调问这一年的迭代，本质上就是在回答上面这些具体问题。所有版本号变化背后，都是这些真实场景在推着走。
1.2 年度版本规划与节奏
分享一下我们实际采用的迭代节奏。调问保持“双月一个大版本，中间穿插 patch 版本”的节奏，重大重构单独开分支验证。3.0 版本完成了题型引擎的组件化重构，3.1 加入了可视化逻辑编排器，3.2 主攻移动端适配和弱网环境下的离线暂存，3.3 上线了实时数据看板和交叉分析，3.4 开放了官方 API 和插件点，3.5 集中做性能优化和安全加固。
这种节奏有几个好处。首先是每个版本都有明确主题，社区用户知道应该关注什么；其次是重构和功能开发分开，不会出现“为了加一个功能把底层模型全打翻”的情况。尤其要提醒一句：对于开源项目，版本规划不只是代码问题，更是社区沟通问题。提前两周发 release note，把 Breaking Changes 列清楚，升级踩坑的人就会少一大半。
2. 核心功能升级拆解
2.1 题型引擎重构：从“填空题集合”到“组件化题型池”
3.0 这一版干了件很“伤筋动骨”的事：把原来写死的题型配置，改成了基于 JSON Schema 的组件化题型池。每一类题型由三部分组成——前端渲染组件、后端校验器、数据存储模板。
用一个具体例子说明。老版本的“多选题”是孤立的，后端代码里写死了一个 multipleChoice 表结构，选项存成逗号分隔字符串，分析的时候再拆分。这个方案在数据量小的时候能用，但一旦涉及矩阵多选项、限选几项、选项随机，就要不断打补丁。重构之后，多选题在后端的状态被抽象成answer_value+answer_meta两个字段，answer_value 存最终答案，answer_meta 以 JSON 格式存原始选择过程、答题耗时、选项顺序等辅助信息。这样结构不僵死，后面加“限选三项”“最多选五个”之类的规则，只需要在选项配置里加一个 min/max 参数，不用改数据库表。
前端同样受益。以前新题型要复制一堆模板代码，现在只需要注册一个渲染组件，声明它需要哪些配置项，逻辑编排器就能自动识别。举个例子，我们要加一个“滑块打分题”，需要配置最小值、最大值、步长、刻度标签。在组件化设计下，这几个配置项是声明式的，后台配置页面会自动生成表单，用户完全不用写代码。
这里有个很值得注意的经验：题型组件化不是把代码拆碎就完事，关键是要定义清楚“组件接口契约”。我们在一开始制定了题目组件的五类标准接口：getConfigSchema返回配置结构，validateAnswer做提交校验，formatAnswer做数据格式化，getStatistics返回统计指标，exportData负责导出格式转换。后面每一个新题型照着这五个接口实现，就不会出现“统计模块不认这种题型”的情况。
2.2 逻辑编排器升级：跳题、配额、随机与关联
问卷逻辑是用户最头疼的部分，也是调问 3.1 花力气最大的地方。升级后，逻辑设置从“写条件公式”变成了“可视化编排”，覆盖了四类常见场景：条件跳转、按条件显示、分值计算和配额控制。
条件跳转这块，现在的实现思路是“节点图”。问卷不是线性题目列表，而是一张有向图，每道题是一个节点，选项和选项之间通过“边”连接。比如第 3 题选 A，下一题显示第 5 题；选 B，直接跳到第 8 题。后台配置时，你只需要选中节点，添加“出口条件”即可。
配额控制是很多问卷系统的隐藏痛点。做市场调研时经常有这样的需求：性别配额，男 200 份、女 200 份，满了自动关闭入口。调问在 3.1 里把配额做成了独立的统计服务，每次提交答卷后异步更新配额计数，而不是同步查库。原因很简单：如果同步查库，高并发下两个请求同时读到配额还剩 1 份，都会进入问卷，最终配额就被击穿了。异步计数配合 Redis 的原子自增，才能保证“配额不超发”。
随机化和题目关联也在这版做了增强。随机分组可以按用户维度固定，比如用户一进来就被分到 A/B 两组，整个问卷看到的内容不同，这个场景在用户体验调研里非常常用。题目关联支持跨卷引用，比如第一题填了“城市”，后面某个题可以自动填充“该城市是否支持异地还车”这类关联条件，相当于一个小型计算引擎。
实操中有一个高频坑：逻辑层做得越复杂，后端校验就越要兜底。有些用户会绕过前端页面，直接模拟 POST 提交答卷，如果后端不校验题目之间的跳转依赖，就会收到一堆脏数据。我们在 3.1 之后专门加了一个“后端逻辑校验模式”，每次提交时用同一套规则引擎跑一遍，凡是不符合当前逻辑路径的答卷，直接标记为异常，不进入统计范畴。这个设计救了我们很多次，强烈建议做问卷系统的开发者参考。
2.3 数据回收与分析：从“导出Excel”到“实时数据看板”
3.3 升级把数据分析能力提升了一大截，原来的“下载答卷 Excel”变成了标配功能之一，新增了实时看板、交叉分析、趋势图和答卷质量过滤。
实时看板基于 WebSocket 推送，问卷回收页一打开，回收数量、完成率、各选项占比都在动。这里的技术挑战是统计实时性。如果每次都从 MySQL 里做聚合查询，数据量大了会很吃力。我们的做法是：答卷提交后，先把原始数据写 MySQL 保证持久化，同时异步把关键指标写入 Redis 的 Hash 结构中，看板查询只读 Redis。
交叉分析功能看着简单，其实要解决“分析维度”和“题干”两张表的动态组合问题。用户要的不只是“满意度平均分”，而是“不同部门的满意度对比”甚至“不同部门、不同职级、不同入职年限的满意度对比”。实现上，我们把统计维度抽象成dimension和metric两个概念，dimension 是分组依据，metric 是指标计算方式，然后在内存中做二次计算。踩过的坑是内存占用：如果一次交叉分析拆出几十万个单元格，后端会直接 OOM。后续加了结果缓存和限定最大单元格数，超过阈值自动提醒用户缩小维度范围。
答卷质量过滤是很多人忽略但实际很需要的功能。我们实现了一套规则引擎，支持按“答题总时长”“单题平均时长”“连续同一选项数”“前后逻辑矛盾”等维度标记废卷。比如一份 20 题的问卷，总答题时间不到 15 秒，或者 20 题全部选了同一个选项，这类答卷默认进入“异常答卷”分组，统计时可以选择剔除或保留。这个功能在教育行业使用率特别高，很多老师做测试卷回收后就靠它筛选无效样本。
3. 技术架构演进
3.1 服务端框架升级与 API 层规范化
服务端技术栈从 PHP 8.1 升到了 PHP 8.2，框架从 Laravel 9 升到了 Laravel 10。升级带来的直接收益是性能提升和新的语言特性，但这一年的主要变化并不是“框架版本号”，而是 API 层的规范化和模块化。
我们在 3.4 版本实现了完整的 RESTful API 和 OpenAPI 3.0 文档，所有接口统一走/api/v1前缀，鉴权采用 Bearer Token 方式，支持项目级 API Key。这里重点说下为什么一定要做 API 规范化：问卷系统如果要接第三方业务系统，最典型的场景是“用户填完问卷后，把结果回传到企业 CRM”。没有 API 之前，这只能靠开发人员手工写数据库脚本，既不安全也不可靠。有了标准 API，外部系统可以通过POST /api/v1/responses接口提交答卷，通过GET /api/v1/surveys/{id}/stats拉取统计结果，甚至可以通过 Webhook 订阅“新答卷提交”事件。
具体实现上，我们引入了 FormRequest 来做参数校验，用 Resource 类统一格式化返回结构。所有列表接口默认分页，并支持sort、filter、fields三类通用参数。这样设计的好处是，前端看板和分析模块可以完全复用 API，不需要另外写一套内部接口，后续开发效率明显提升。
服务端还有一个不得不提的改造：项目重构了队列任务系统。问卷导入、大量邮件发送、答卷导出这些耗时操作，全部改为异步任务处理。以“导出 10000 条答卷为 Excel”为例，这个操作在同步模式下会阻塞请求好几秒，现在提交导出任务后立即返回“导出任务已创建”，后台 worker 处理完再通知用户下载。任务失败还有重试机制，最多重试 3 次，每次间隔指数退避。
3.2 前端工程化与移动端适配策略
前端这年做了两个核心动作：Vue 3 + Vite 迁移，以及移动端体验重构。Vue 3 的组合式 API 配合 TypeScript，让问卷编辑器和答卷渲染的代码复用性明显提升。Vite 带来的构建速度提升非常直观，开发环境下热更新几乎是秒级。
移动端适配这件事，很多人以为是“加几个断点让页面变窄就行”，实际不是。填问卷的场景跟浏览网页完全不同，用户在手机上时长不稳定，会临时切出去回微信，回来要继续填。所以 3.2 版本做了一套“离线暂存”机制，核心思路是：每个题目的答案先保存在本地（localStorage），离开页面时自动快照，用户回来时一键恢复，不需要重新填前面所有题。
为了兼顾性能和兼容性，我们选择的方案是“本地暂存 + 服务端校验”配合。前端在每次切换题目时写 localStorage，最后提交时一次性提交后端完整 JSON。这里设计了一个问题：部分低版本手机 WebView 的 localStorage 容量只有 5MB，如果一个问卷含大量图片上传题，很容易溢出。解决办法是，本地只存文本答案，图片等二进制文件在弱网环境下降低压缩比后再上传，并且支持断点续传。实测在一个 2 万人规模的校园调研场景下，用弱网模拟工具测试，页面崩溃率从 5.2% 降到了 0.8% 以下，效果很明显。
3.3 性能与扩展性：缓存优化、队列化、插件点设计
3.5 版本的性能优化方向主要有三个：数据库索引优化、缓存层改造、静态资源加速。
数据库方面，重点优化了答卷表和历史统计表的索引。答卷表的核心查询条件是survey_id + created_at，原来的联合索引字段顺序是created_at + survey_id，高并发下经常出现慢查询。把索引调整成survey_id + created_at之后，单表千万级数据量下，常见统计查询从几百毫秒降到了几十毫秒。这个细节特别值得我们反思：索引字段顺序不是拍脑袋定的，一定要基于真实查询模式分析。
缓存层引入了 Redis 多级缓存。问卷结构配置变化频率低，读取频率高，适合做本地内存缓存；答卷计数和配额需要全局一致，放在 Redis 更合适。我们给 Redis 里的数据都设置了过期时间，避免长期占用内存，也防止统计口径和数据库不一致。
插件点设计是 3.4 的另一项重点。为了让社区开发者可以扩展功能，我们在服务端内置了一个简单的插件机制，支持注册自定义路由、自定义命令、自定义事件监听器。插件本质上是一个遵守目录规范的 composer 包，把自己注册到plugin.php配置文件中。这样做的价值在于，如果你觉得官方题型的统计方式不满足需求，可以自己写一个插件覆盖默认逻辑，而不需要 fork 整个项目。
4. 开源治理、部署与合规
4.1 开发与部署：Docker Compose、反向代理、HTTPS
部署体验是这一年的主要打磨点之一。现在调问官方提供了一套完整的 Docker Compose 编排文件，包括web（Nginx + PHP-FPM）、app（PHP 队列 worker）、db（MySQL 8）、redis（Redis 7）四个核心服务。安装过程基本就是三件事：复制.env.example为.env，改数据库密码，执行docker compose up -d，然后访问安装引导页完成初始化。
这里分享下我在部署时踩过的几个坑。第一个坑是 PHP-FPM 的upload_max_filesize和post_max_size默认值太小，默认 2MB 根本没法上传大图片。一定要在 Dockerfile 或者环境变量里把这些值调大。第二个坑是队列 worker 的并发数。默认配置是php artisan queue:work --sleep=3 --tries=3，并发数不高够用，但如果你做了“答卷推送 webhook”这种依赖队列的业务，建议跑多个 worker 进程，并加上--max-time=3600防止内存泄漏。第三个坑是时区设置。容器默认 UTC 时区，如果你不做配置，统计图里的“今日回收”会对着 UTC 时间显示，会晚 8 小时，看起来特别诡异。在.env里设置APP_TIMEZONE=Asia/Shanghai，同时把 MySQL 和 PHP 的时区统一，就没问题了。
反向代理方面，我一般建议 Nginx 直接暴露 80/443 端口，容器内部只监听内网端口。配置要点是 WebSocket 必须设置Upgrade头，否则数据看板的实时推送会断开。SSL 证书用 Let's Encrypt 免费证书即可，建议开启 HTTP/2，对移动端弱网环境有明显改善。
4.2 开源许可证选择与合规管理
开源许可证这事，很多项目早期不太在意，但越往后越重要。调问选择的是 GPL v3 许可证。为什么是 GPL v3 而不是 MIT 或 Apache 2.0？核心原因是我们希望这个项目保持“修改后也要开源”的约束，让社区改过的版本能回流上来，避免出现“开源版引流、闭源版收割”的局面。这个决策有利有弊，好处是代码始终开放，坏处是某些企业客户因为合规原因不接受 GPL v3，更希望有一个商业授权的宽松许可。所以我们同时提供一个“商业授权”选项，企业付费后可以获得闭源使用的权利。
如果你也在管理一个开源项目，我建议尽早把许可证和贡献者协议（CLA）定下来。Gitee 平台创建项目时让选的许可证模板可以直接参考，但真正的细节要结合项目实际情况看。比如你的项目如果依赖了其他开源库，要考虑它们的许可证是否兼容 GPL v3；如果项目计划商用，最好单独找法务过一遍。
在实际操作中，我们还做了一套开源合规自查清单：每个代码仓库都要有 LICENSE 文件；每个第三方依赖都要在THIRD_PARTY_NOTICES.md里记录许可证类型；每次发版前用自动化脚本扫描依赖许可证冲突。这套机制见效很快，社区用户反馈说“这个项目终于敢在生产环境里用了”。
4.3 安全加固：防刷、防注入、数据加密
问卷系统的安全问题不显眼，但真出问题就是大事。最典型的风险有几类：机器人批量刷卷、SQL 注入、答卷数据泄露、未授权访问配置接口。
防刷方面，我们在 3.5 加入了“智能风控模块”。每个用户会话会生成一个设备指纹，结合 IP、User-Agent、提交速度等信息，综合计算风险分。如果风险分过高，自动弹验证码；如果连续多次异常，直接拉黑该设备指纹。这套机制上线后，在一场线上有奖调研活动中，有效拦截了大约 37% 的机器人请求，数据质量明显提升。
SQL 注入和 XSS 的主要防护措施是使用 Laravel 的 ORM 参数绑定和 Blade 模板默认转义。但对问卷这种用户输入特别灵活的系统，还要注意“存储型 XSS”的风险：答卷内容里如果包含恶意 HTML，管理员在看答卷详情时就会被攻击。我们的处理方式是，所有用户输入的文本在渲染前统一做白名单过滤，只允许常用标签，其他全部转义。
数据加密方面，答卷中的隐私字段支持 AES-256-CBC 加密存储。管理员可以配置哪些字段属于敏感字段，配置后这些字段在数据库里以密文形式保存，API 返回时也要单独申请解密权限。这个功能在医疗、金融类客户那里被反复提到，算是我们的一个重要竞争力。
5. 应用场景与影响范围
5.1 企业内部调研：一个很典型的落地案例
调问这一年最典型的使用场景之一，是企业内部调研。有家连锁零售企业用调问做员工满意度调查，覆盖了 4000 多名员工，涉及门店、总部、仓储等不同岗位序列。它们的需求非常典型：问卷要按事业部隔离——门店员工看不到总部专属的问题，基层员工和管理层题目也不同；题目要支持矩阵量表，要按门店维度交叉分析“薪资满意度”和“离职意向”的相关性。
这套需求落地后，我在他们复盘时注意到两个细节很有参考价值。第一，配额控制阻止了重复填报。HR 设置了“每个员工唯一答卷”规则，通过员工工号绑定，同一工号只能提交一次。之前用第三方免费问卷工具，员工反复提交也没法识别。第二，交叉分析导出成 PPT 报告的时间从原来的一个工作天缩短到了半小时。HR 需要按大区、部门、司龄三个维度切片，实时看板直接生成图表，不用再让 IT 部门拉数据。
调问在私有化部署上也发挥了作用。企业数据不能出内网，用 Docker Compose 部署在公司服务器上，所有数据物理隔离，这满足了他们内部合规要求。这种使用方式比 SaaS 问卷工具更有吸引力，也是开源问卷系统的重要价值点。
5.2 高校科研与课堂反馈
高校用户是开源问卷系统的主力人群之一。调问在校园场景的使用方式，和商业场景不太一样：他们更看重自由度、可复现性、原始数据导出和二次计算能力。
一个比较有代表性的科研场景是心理学系的问卷实验。研究人员需要把被试者随机分成两组，一组看传统描述，一组看干预描述，然后比较量表得分差异。调问的随机分组功能正好命中这个需求——按用户维度固定分组，保证同一被试不会重复进入实验。数据导出要支持 SPSS 格式，量表题要能自动计分。这些功能单独看都不复杂，但结合起来，对系统的要求就上了一个台阶。
课堂反馈是另一个高频场景。老师发一个随堂问卷，学生扫码填写，老师屏幕上实时看到回收进度。这里的强需求是移动端体验：不能有复杂注册流程，扫码即填；弱网环境不能卡死；结束后可以快速导出 Excel 格式的成绩单。调问 3.2 的移动端优化和离线暂存机制，让课堂场景的容错率大幅提升。有老师反馈说，以前用传统工具做课堂测验，总有十几个学生因为手机网络问题提交失败，换成调问后基本没了。
5.3 线下活动与快闪调查
线下活动的场景往往是最考验系统稳定性的。展会调研、快闪店访问量调查、峰会签到问卷，这些场景有几个共同特征：集中在短时间内爆发、移动端为主、需要快速部署。
有一场行业展会，我们帮主办方部署了调问系统，两天时间回收了 6000 多份问卷。当时配置了 4 个 Web 容器和 2 个队列 worker，数据库做了主从。回收高峰出现在第一天上午十点到十一点，每分钟大概 100 份提交，系统负载维持在可控范围内。这里的核心技术是缓存和队列的配合：题目配置全部走本地缓存，提交只写 Redis 和数据库队列，不让实时查询拖累写入性能。如果没有这些优化，单纯依赖 MySQL 同步写入，极可能在高峰期出现锁表。
线下活动场景还让我发现一个体验细节：二维码分享页面一定要做移动端适配的“真实验证”，而不是只在浏览器开发者工具里切一下模拟视图。很多低端安卓机的浏览器兼容性比想象中差，CSS Grid 布局不支持、WebSocket 连接不稳定、旧版 WebView 对 ES6 模块支持不全，这些都可能让活动页面直接白屏。建议至少拿 3 台不同品牌的千元级安卓机真机测试一遍再上线。
6. 常见问题与排查实录
6.1 部署安装类问题
这个分类的问题最多。第一个高频问题是“Docker 启动后 502 Bad Gateway”。大多数时候不是容器本身的问题，而是 PHP-FPM 还没完全启动，Nginx 已经提前开始服务了。等待 10 秒再刷新一般就正常。如果一直 502，进容器执行php-fpm -t看配置项有没有语法错误。
第二个是“数据库连接失败”。.env 文件里的DB_HOST要写成 docker-compose 中的服务名db，不能写成localhost或127.0.0.1。还有 MySQL 8 默认认证插件是 caching_sha2_password，部分老版本 PHP 驱动不支持，建议在数据库初始化 SQL 里显式创建用户并指定 mysql_native_password。
第三个是“后台登录后看不到任何菜单”。大概率是 Redis 缓存了旧版本的权限路由，执行php artisan optimize:clear清一下缓存就行。还有一个很低级但常见的错误：上传代码时没有把.env文件一起传上去，框架会报 “No application encryption key has been specified”，执行php artisan key:generate生成即可。
6.2 功能与配置类问题
功能配置类的问题也不少见。有人问“为什么我设置了逻辑跳转，但用户填的时候没有生效”。排查思路分三步：先看跳转条件是否设置了正确的选项值；再看是不是有多个条件互相冲突，比如一个条件说“跳到第 5 题”，另一个条件说“显示第 3 题”；最后查看答卷记录的answer_meta，确认前端提交的数据确实走了新逻辑分支。
还有人问“为什么配额明明设置了 200，实际回收到了 205”。这可能是并发时异步计数覆盖导致的问题。检查 Redis 中配额 key 的更新逻辑，要使用INCR原子自增并配合 Lua 脚本做“超过上限则拒绝”的判断，而不是用“读取-判断-写入”这种非原子操作。
邮件发送问题也很常见。调问支持 SMTP 发送问卷链接和答卷通知，很多人配置后收不到邮件。先开日志确认MAIL_MAILER是否设置成smtp，再确认 SMTP 的 host 是否允许外部连接。如果是 QQ 邮箱，要使用授权码而不是登录密码。
6.3 性能与数据类问题
性能问题最常见的表现是“回收量一大，后台统计页面就变慢”。如果你在管理端使用实时看板，先确认 Redis 是否正常，因为看板数据主要从 Redis 读取。实时看板变慢时，一般不是 Redis 本身的问题，而是有大量无效的 WebSocket 连接挂着，Nginx 的worker_connections被耗尽。建议在 Nginx 配置里给 WebSocket 设置合理心跳，并定期清理无效连接。
数据导出慢也很常见，特别是导出大量答卷为 Excel 时。默认的 PHPExcel 库处理几万行数据就会内存溢出。我们的解决方案是分段查询加流式写入，每次只取 1000 条，写入临时文件后合并下载。另外导出任务建议放队列异步执行，浏览器端轮询导出状态，最终拿到下载链接，而不是同步等待。
还有一个数据一致性问题值得单独提醒：如果你在 Redis 中做了答卷计数缓存，缓存和数据库一定要有对账机制。我们每天凌晨跑一个定时任务，重新统计各问卷的答卷数，并和 Redis 中的计数做对比，偏差超过 5 就自动告警。这个机制上线以后，类似“回收数和答卷列表数量不一致”的工单基本消失了。
最后再分享一点我这轮迭代的体会
这一年的迭代里，我最深的体会有两点。第一，问卷系统的代码难度不在“写出来”，而在“扛得住”。扛得住各种奇怪的逻辑组合、扛得住高峰期大批量提交、扛得住第三方系统各种不规范的调用方式。第二，开源项目的路不是代码写得好就能走通，许可证选型、社区文档、issue 回复速度、发版节奏，这些“非代码工作”往往决定了你的项目能走多远。
如果你正准备在自己的业务中引入一套开源问卷系统，我的建议是：先把你最复杂的三个问卷场景跑一遍 POC，而不是只看功能列表。功能列表上的“支持逻辑跳转”和实际配置出“多级嵌套带配额限制的跳转逻辑”，完全是两回事。如果你已经部署了调问，遇到问题也别急着提 issue，对着每个版本的发版说明和配置文档先自查一遍，六七成问题都能自行解决。
以后这个项目还会继续在 AI 辅助分析、更细粒度的权限模型和更多插件生态这几个方向上推进。我个人对“开源问卷系统”这件事的判断是：只要数据主权意识还在抬头，私有化、可扩展的问卷工具就永远有需求，这也是调问持续迭代下去的根本原因。
