一、先说说我自己：从前端被裁，到全职做一个产品
先简单介绍一下我自己：我原本是一名前端工程师，写了很多年前端，在几家公司待过。去年行业整体环境不太好，裁员潮的时候我也没躲过去。刚被裁那阵子，确实有一段时间挺迷茫：
- 一边刷招聘，要么岗位不多，要么要求很高；
- 一边在想：要不要趁这个机会，做点真正属于自己的东西？
之前在公司里，我经常要用各种问卷工具（问卷星、金数据之类）做需求收集、活动报名、调研等等。用得久了，心里一直有一些不爽：
- 明明只是一个问卷平台，稍微复杂一点就得升级高价套餐；
- 想在公司内部自建或做深度集成，几乎没有好用、可维护的方案；
- 小程序一套、PC 一套、官网一套，前后端割裂，数据和权限很难统一；
- 想加一个自己的题型、业务逻辑，扩展性很一般。
被裁之后，我就干脆做了一个决定：> 不再只做「页面搬运工」，而是全职把一套自己的问卷系统打磨出来——> 这就是现在的 「轻松收集」。顺便说一句：「轻松收集」是一套支持小程序 + PC 端的问卷 / 表单系统，更适合自建、扩展和和业务深度结合。
二、「轻松收集」到底能做什么？
先从产品视角，快速过一遍现在已经上线的能力。
1. 多端一体
- 官网：产品介绍 + 登录入口
- 访问地址：
- PC 端管理台：创建问卷、管理答卷、查看统计，更适合同事和运营使用
- 访问地址：（推荐用电脑打开）
- 后台管理：更多系统级配置能力
- 访问地址：
- 小程序端：发布问卷、收集答案，适合用户/客户在手机上随手填写
-（这里你可以写上小程序的真实名称，便于搜索）
2. 问卷创建与管理
- 支持多种题型：单选、多选、填空、矩阵、评分、图片/文件上传、地址、手机号、订单号等。
- 问卷可以按文件夹管理，有草稿、已发布、回收站等状态。
- 支持基本的逻辑控制、必填校验和填写限制（比如限制每个用户/设备提交次数）。
3. 用户体系 & 登录方式
- 支持账号密码登录；
- 支持 手机号 + 验证码登录 / 注册（对纯 PC 用户体验很重要）；
- 支持微信相关登录方式，用于小程序场景。
4. 数据统计与导出
- 基础统计：答卷数、参与人数、各题目的选项占比；
- 支持查看单条回复详情、筛选列表；
- 支持导出 Excel 等格式，方便后续做二次分析。
三、我为什么要自己造这套轮子？
很多人会问：“问卷星、金数据这些不都挺成熟的吗？你干嘛自己重做一套？”我真实的几个痛点：
- 自建 / 私有化需求
有些业务，对数据安全和内网集成要求比较高，把所有数据放在第三方不合适，或者想打通内部用户体系，这时候 SaaS 就很别扭。
- 前后端深度结合
作为前端，我很清楚：当你想让「小程序 + H5 + PC 管理台 + 官网」都对接同一套能力时，如果底层不是自己可控的，很快就会走到「到处打补丁」那条路上。
- 可扩展性
真实业务里的题型和逻辑，远比普通问卷要复杂：
- 比如手机号、姓名、地址、订单号这些强业务属性字段；
- 比如复杂的逻辑跳转、校验规则、防刷策略等等。
这些如果不能比较优雅地扩展，长期维护会非常痛苦。被裁之后，我不太想再回到纯「项目制搬砖」模式，所以索性把这些痛点变成「轻松收集」的设计目标：让它成为一个可以长期打磨、可以深度集成的“问卷内核”。
四、整体技术架构（从前端工程师视角出发）
我是前端出身，所以技术选型有个硬要求：自己一个人也要能扛得住。最终落地的技术架构大概是这样：
- 后端：Node.js + Express + MongoDB
- 提供统一的 RESTful API，对接小程序和 PC 端；
- 使用 JWT 做鉴权；
- 用 Mongoose 管理各种模型：User、Questionnaire、Question、Response、Points、UserLoginLog 等。
- 小程序端
- 主要承担问卷填写、结果展示的功能；
- 通过 HTTPS 调用后端 API，使用 token 鉴权。
- PC 管理端 & 官网
- 使用熟悉的 Web 技术栈开发（你可以在文中填上 React/Vue 等）；
- PC 管理端负责问卷创建、管理、统计；
- 官网负责产品介绍、引导注册/登录和承接自然流量。
一句话概括：> 小程序 / PC / 官网> → 统一后端服务（认证、问卷、积分、统计）> → MongoDB 存储业务数据
五、技术细节 1：认证体验 vs 安全性的平衡
做产品和做纯 Demo 不一样，有两个看似矛盾的需求：
- 生产环境必须严格认证，不能给“默认用户”乱放行；
- 开发环境前端调试，又不想每改点东西就重新登录一遍。
在「轻松收集」里，我是这样拆的：
- 定义几类基础中间件：
- authenticate：严格认证，没有 token 就 401。
- optionalAuth：有 token 就解析，没有也不报错，适合公开接口。
- optionalAuthWithDefaultUser：开发阶段用，没有 token 时给一个“默认用户”，方便前端调试。
- 在此基础上，封装了一个专门给 PC 端用的中间件：pcAuth：
- 在 生产环境 (NODE_ENV === 'production')：
- pcAuth 等价于 authenticate → PC 相关接口（如 /api/pc/questionnaires、/api/pc/dashboard、/api/users、/api/points 等）必须登录。
- 在 开发环境：
- pcAuth 等价于 optionalAuthWithDefaultUser → 没 token 也能用默认用户跑通整个流程，减少登录打扰。
这样做，基本兼顾了：
- 安全性：生产环境完全回到「必须登录」的传统模式。
- 开发效率：本地调试不被登录流程拖慢。
- 代码整洁：PC 相关路由统一 router.use(pcAuth)，不用在业务代码里到处写环境判断。
六、技术细节 2：问卷模型设计，不只是随便存 JSON
很多表单/问卷系统实现喜欢一股脑把问题塞进一个大 JSON 里，短期可以跑通，长期很难维护。在「轻松收集」里，我做了几件事：
- 题型统一用枚举管理
比如：
- 常规类型：single、multiple、text、textarea、rating、matrix…
- 业务增强类型：location、name、phone、email、address、order-number 等。
好处是：
- 前端拿到 type 就能渲染对应组件；
- 后端可以按 type 做各自的校验/统计逻辑，避免「全 if/else 大泥团」。
- 为易变字段设置合理默认值
例如：
- 问题标题、问卷标题，从强制 required 改为有 default 的可选字段，比如「未命名题目」「未命名问卷」；
- 地址格式、评分最大值等配置型字段，用 enum + default，而不是全靠前端。
这样，在草稿阶段不会因为「还没填完」就被后端校验一直打回来。
- 向后兼容的数据演进
当要新增字段或扩展配置时，通过调整 enum、设置默认值来保护历史数据，避免老问卷突然“打不开”。总体目标是：让这套问卷模型扛得住长期的扩展，而不是写完一版就不敢动。
七、技术细节 3：登录日志，为未来的安全和运营留钩子
还有一个模块，是我刻意加进去的：用户登录日志（UserLoginLog）。每次登录成功（注册成功后的首次登录、账号密码登录、手机号登录、微信登录），都会记录一条日志，包括：
- 用户 ID；
- IP；
- User-Agent；
- 设备信息；
- 登录时间（带索引）。
短期看，它可能只是一张“看起来没什么用”的表；但长期看，它是很多能力的基础：
- 安全角度：可以分析异常 IP / 设备行为，做简单风控；
- 运营角度：可以看高频用户、登录活跃时间段等；
- 产品角度：如果以后想做「异地登录提醒」「登录通知」，也有数据可用。
八、欢迎你亲自体验一把
我现在是一个全职在做「轻松收集」的独立开发者，最缺的其实就是真实用户的反馈。如果你愿意帮个小忙，可以这样体验一下当前版本：
- PC 端体验
- 打开浏览器访问：
- 用手机号登录、随便创建一份自己的问卷玩玩。
- 小程序扫码体验
- 用微信扫一扫下面的小程序码，进入「轻松收集」体验问卷填写。
在这份「读者问卷」里，你可以随便说：
- 你现在用什么问卷工具？最烦的点是什么？
- 你会在哪些业务场景用到问卷 / 表单？
- 对「轻松收集」你最想先看到的功能是哪几个？
我会认真看完每一条反馈。
九、写在最后：从被裁到全职做产品
从被裁，到现在全职做「轻松收集」，中间有过焦虑，也有过兴奋：
- 焦虑是因为不确定：这个东西到底能不能跑起来，会不会只是一个「自嗨项目」；
- 兴奋是因为：第一次感觉自己不只是“接需求的人”，而是在亲手搭一个完整的产品。
如果你：
- 正在做或考虑做自己的产品；
- 或者在公司里，也有自建问卷/表单平台的需求；
- 又或者，单纯对「一个被裁前端如何全职做产品」这件事好奇，
欢迎在评论区聊聊。如果你愿意帮我这个独立开发者一把，也非常欢迎你：
- 点个赞 / 收藏 这篇文章，让更多人能看到它；
- 打开 或扫上面的小程序码，
实际体验一两次，并在那份「读者问卷」里留下你的真实想法。对我来说，每一个真实的访问、每一条认真写下来的反馈，都是在帮我把「轻松收集」这件事，往前推一点点。
