205 lines
7.9 KiB
Plaintext
205 lines
7.9 KiB
Plaintext
这些图片中的内容是关于IM即时通讯的软件，你识别图片中的内容，整理为需求文档，包含图片，功能说明
|
||
上面是一张图片，下面就是说明，功能的标题就是图片的名称，说明的时候将功能相关的放一起，我希望是这样的
|
||
1.相关功能图片的总体功能（需要你总结一个标题）
|
||
1.1 图片名称
|
||
图片
|
||
功能说明：
|
||
图片内容的描述
|
||
写成一个md文档，要在md文档中可以看到图片
|
||
|
||
|
||
密码aes 加解密 密码能够加解密
|
||
聊天内容加密
|
||
聊天内容的监控
|
||
用户的类别
|
||
后台生成的有标识
|
||
登录设备做标识 移动
|
||
登基日志 连续N天设备登录
|
||
多通过配置的方式处理 前端不要写死
|
||
|
||
一定要考虑好群聊的推送问题
|
||
离线和在线状态存到redis里面 这个是一个难点
|
||
离线的我们的服务不推 走极光的推送
|
||
在线的直接ws推
|
||
多用开关
|
||
|
||
校验营业执照
|
||
|
||
第三方
|
||
短信
|
||
kyc
|
||
营业执照
|
||
声网 Agora 音视频服务
|
||
极光推送 离线 Push 服务
|
||
oss对象存储
|
||
文件安全扫描 / 内容安全服务
|
||
|
||
|
||
admin后台群操作通过kafka投递到c端 c端通过ws传到客户端
|
||
记录先放到Kafka、 再异步落库。用考虑重复落库的可能
|
||
|
||
1. 有 IM 即时通讯项目开发经验优先；
|
||
2. 熟悉消息可靠性、消息时序、ACK 机制、消息去重、离线消息处理；
|
||
3. 熟悉群消息扩散策略，如读扩散、写扩散；
|
||
4. 理解多端同步、消息漫游、消息推送等 IM 核心机制；
|
||
5. 有 OpenIM 或类似 IM 项目经验优先。
|
||
|
||
1.注册增加邀请码 （非必填 ）不填邀请码可以正常注册。只要手机号符合11位格式就行
|
||
2.验证码验证作为开关 关闭的情况下的话后台不向短信服务商发送请求，前端正常ui的倒计时，但是收不到验证码
|
||
3.正常不填邀请码，用真实手机号注册的，且后台开关打开的情况下，可以收到验证码的流程也能正常注册
|
||
|
||
这个是现在的情况
|
||
后台开关在系统设置 字典管理 增加一个系统枚举 系统开关的 ID = 171
|
||
|
||
用户的唯一标识用user_id来标记，然后新增user_name，也就是用户名字段
|
||
|
||
|
||
看看对接文档1.4的注册页面 增加逻辑 1.注册邀请码 （非必填 ）不填邀请码可以正常注册。用真实手机号注册的，且后台发送注册验证码的开关打开的情况下，可以收到验证码的流程也能正常注册
|
||
2.发送注册验证码的开关关闭的情况下，后台不向短信服务商发送请求，前端正常ui的倒计时，但是收不到验证码，此时填了邀请码，且邀请码校验合格的话，没有验证码仍然可以注册
|
||
|
||
我看了很多users相关的表 你总结一下分别是什么作用
|
||
你看看手机号是如何存的
|
||
im_users的 tags 有啥用 存的啥
|
||
|
||
昵称用中文实现
|
||
|
||
对一样的，因为给好友改了备注，所以上面就会显示，但是昵称是好友，本身自己起的网名，如果对方没有起，系统会默认给一个
|
||
|
||
用户名和手机号注册的话 如果验证码开关是开的 以验证码为准 如果没开 就以邀请码流程 用户名不能忽略 要保存
|
||
|
||
前后端对接文档 补充 请求和响应的json
|
||
|
||
文档的覆盖测试
|
||
|
||
发的网站功能的复制
|
||
web地址：https://web.xcwykk.top/
|
||
管理后台地址：https://admin.adfahi.cn
|
||
账号：heiyue
|
||
密码：Heiyue123
|
||
测试名额：100
|
||
|
||
群操作
|
||
文件操作
|
||
|
||
redis的接入 性能提升
|
||
kafka的接入 异步操作 幂等性
|
||
|
||
弱网
|
||
QUIC传输技术
|
||
日志框架的接入
|
||
|
||
|
||
重中之重。加密 + 接口鉴权 防止被扫 日志要记录下来 每个小时告警
|
||
|
||
法相 （三方IM 资金电话确认）, [Aug 27, 2026 at 22:13:24]:
|
||
....进群的时候拿群成员列表信息 这个怎么做成缓存 然后怎么更新缓存
|
||
2.多标签要独立的登录状态，可以用不同域名来解决这个问题，但是要token过期时间要限制一下 7天或者10天 每次登录都重置这个时间
|
||
3.转发消息 涉及到转发群和转发个人 大批量转发 消息会不会串
|
||
4.我在第一个标签转发了100个群，然后直接切换到第二个标签，你第一个标签还没转发完 你该怎么处理 会不会串到第二个标签页
|
||
|
||
|
||
群成员信息这个是很耗性能的 一个群几千个人 你要考虑是进一次就拿一次群成员信息 还是拿一次
|
||
网页上一个tab一个用户
|
||
|
||
|
||
我说的进不是给你拉进群 是你点击群聊这个会话框
|
||
|
||
|
||
敏感词 开关
|
||
|
||
组织机构树的处理逻辑 我现在处理逻辑
|
||
|
||
1，手机号注册，或者上架用的测试账号 可以看到好友的组织结构，
|
||
|
||
2，通过邀请进来的 只能看到自己
|
||
|
||
|
||
对了，强调一点，移动端所有加好友的入口都是需要后端控制的，管理后台需要开关控制能不能加好友。
|
||
然后还要增加宵禁功能，宵禁功能是单聊私聊都不能发消息。这个也是管理后台控制的。
|
||
|
||
tinode 移除
|
||
监控接口
|
||
制定联调计划
|
||
|
||
多租户的测试
|
||
|
||
不能全存
|
||
|
||
图片只存oss地址 给前端的是oss地址 文件也是oss地址
|
||
本地只存100条 历史分页50条拉
|
||
群聊要跨月建表
|
||
|
||
|
||
|
||
聊天的菜单元素是前端写死的么
|
||
|
||
群成员变动发消息 然后拉取 群成员 要考虑何时全部 何时只是一个
|
||
|
||
只有加入的群管理消息都可见 其他的比如移除啥的 只有管理可见
|
||
|
||
离线用户的推送 未读消息数的处理 每个用户的不一样 群成员每个消息的推送
|
||
|
||
前端返回一个现有序号 后端跟最新序号比对 然后一减 就是未读消息
|
||
|
||
全局禁止加好友 比如下班时间到了 不能加 从群成员去看 不能显示个人信息 个人名片也不能看 二维码也不能加
|
||
|
||
阿里云的oss放一个域名清单 要加密
|
||
设备类型 ip 全部采集入库
|
||
离线时间 和上线时间的采集
|
||
检查一下多处存同一个信息的。尤其是用户的
|
||
|
||
|
||
音视频要加上开关 控制前端的显示 已经处理
|
||
|
||
拆成工作台 + IM
|
||
|
||
文案部分全部拆出来 做配置
|
||
|
||
个人注册的企业码是默认system 不需要企业码的位置
|
||
|
||
先是企业合作，填写信息，审核之后得到企业码
|
||
企业注册的要带上企业码
|
||
|
||
kafka批量消费 批量落库
|
||
|
||
1.进群的时候拿群成员列表信息 这个怎么做成缓存 然后怎么更新缓存
|
||
2.多标签要独立的登录状态，可以用不同域名来解决这个问题，但是要token过期时间要限制一下 7天或者10天 每次登录都重置这个时间
|
||
3.转发消息 涉及到转发群和转发个人 大批量转发 消息会不会串
|
||
4.我在第一个标签转发了100个群，然后直接切换到第二个标签，你第一个标签还没转发完 你该怎么处理 会不会串到第二个标签页
|
||
|
||
新增图片的功能 ？？
|
||
拉一下git提交记录 已经处理
|
||
多实例 断线重连 其他ws的坑
|
||
|
||
|
||
### 1. Fitness-Food（GitHub，MIT 协议｜中文友好！重点推荐）
|
||
|
||
🔗 [https://github.com/saudademjj/fitness-food](https://github.com/saudademjj/fitness-food)
|
||
|
||
- 定位：**中文智能饮食管理系统**，完全匹配你的健身 APP 饮食模块
|
||
- 自带接口能力：
|
||
- 输入中文食物名称，返回全套营养素（热量 / 蛋白 / 碳水 / 脂肪、微量元素）
|
||
- 三餐记录、每日营养汇总、目标对比（减脂 / 增肌）
|
||
- PostgreSQL 内置中文食物库
|
||
- 技术栈：Next.js + Postgres，可以单独拆出后端 API 给你的 APP 调用
|
||
- 协议：MIT，可商用，二次开发无压力
|
||
我打算弄一个饮食健康的产品，主要是想记录三餐，目标对比，返回食物热量
|
||
|
||
默认system企业
|
||
内容审核要根据企业来分。做成开关 新建企业的时候加上
|
||
用户要和商户绑定 进去只能看某一个商户的数据 这个要改造 要从多商户的角度思考系统还有哪些问题
|
||
|
||
调研：
|
||
阿里云上传apk包 下载下来就装不上
|
||
|
||
|
||
各个厂商push的申请
|
||
|
||
新加一个状态，消息免打扰后，对方发消息，红点这么显示
|
||
|
||
Bundle ID：com.ysl.IM
|
||
KEY ID：J4ZUVHW59G
|
||
Team ID：2DN6KF37CH
|
||
|
||
|