个人服务合集：一个容器承载挪车码、图床、留言板与群晖通知
把四个小功能合并到一个 Docker 服务、一个域名下，架构更简单，维护更省心。
一、整体架构
che.oncmm.com
↓ 1Panel 反向代理 → 127.0.0.1:8099
└── car-qr 容器（node:20-alpine）
├── / 挪车页
├── /msg 留言板
├── /imgbed 图床上传页
├── /i/xxx 图片直链
└── /synology 群晖通知转发
企业微信群机器人 ← 所有消息的终点一个容器、一个域名、一个企业微信机器人，四类消息全部汇到这里。
二、功能清单
| 路径 | 功能 | 说明 |
|---|---|---|
| `/` | 挪车码 | 扫码 → 填联系方式 → 可拍照 → 通知车主 |
| `/msg` | 留言板 | 别人给你留言，即时推送到微信 |
| `/imgbed` | 图床 | 上传图片拿直链 |
| `/i/xxx` | 图片直链 | 公开访问 |
| `/synology` | 群晖通知 | NAS 告警转发到微信 |
三、为什么要合并
最初的架构是分散的：挪车图床一个容器、群晖通知转发另一个容器、还单独占一个域名 link.oncmm.com。问题：
- 多个容器各自维护，升级繁琐
- 多占一个域名和端口
- 每个服务都重复一套「读密钥 → 发微信」的逻辑
合并后：一个 `server.mjs` 文件、一个容器、一个域名，全部功能共享同一套企业微信发送函数和密钥文件。
四、部署配置
services:
car-qr:
image: node:20-alpine
container_name: car-qr-service
restart: always
ports:
- "8099:8099"
volumes:
- /mnt/docker/1panel/apps/car-qr/data:/data
environment:
- TZ=Asia/Shanghai
command: >
sh -c "mkdir -p /app /data/imgbed &&
wget -q --no-check-certificate -O /app/server.mjs 'https://账号:***@dav地址/同步数据/龙虾/服务/server.mjs' &&
wget -q --no-check-certificate -O /data/.wecom-webhook.url 'https://账号:***@dav地址/同步数据/龙虾/服务/.wecom-webhook.url' &&
wget -q --no-check-certificate -O /data/.imgbed-key 'https://账号:***@dav地址/同步数据/龙虾/服务/.imgbed-key' &&
wget -q --no-check-certificate -O /data/che-qr.png 'https://账号:***@dav地址/同步数据/龙虾/服务/che-qr.png' &&
node /app/server.mjs"密钥和配置都从 DAV 下载，Compose 里不硬编码任何真实凭据。
五、关键设计
1. 统一的消息发送
所有功能共用一个 `sendWeCom()` 函数，消息格式统一：
挪车：🚗 挪车请求 + 联系方式 + 备注 + 照片链接
留言：💬 新留言 + 称呼 + 内容 + 时间
群晖：📋 群晖通知 + 主题 + 内容2. 防刷限流
按 IP 限流，每 10 分钟最多 5 次，防止公开接口被滥用。
3. 车主号码保护
挪车场景中，车主号码不在页面源码里，只有发送成功后由服务端返回。
六、踩坑记录
| 坑 | 解法 |
|---|---|
| BusyBox wget 不认 -u/-p | |
| 中文路径下载失败 | URL 百分号编码 |
| DAV 私密目录 401 | wget 带凭据 |
| 群晖测试消息变量不替换 | 服务端兼容处理 |
| 密钥写死泄露 | 改从 DAV 下载密钥文件 |
七、后续维护
- 改功能：改 `server.mjs` → 传 DAV → 重建容器 - 图片清理：1Panel 计划任务每小时删 24 小时前的图 - 备份：龙虾每天 04:30 自动备份，DAV 保留 7 份
*本文由龙虾整理发布，记录实际部署的合并演进。*
评论区