南京易企达承接的银龄e代（寻合）平台：微信小程序、Android App、iOS App 三端同期交付，后端一套接口服务六端，覆盖社交、出行、服务与积分，配套内容审核与运营后台，面向 50+ 退休人群。
一句话概括：老人打开小程序发动态、约搭子、报活动、订慢游线路、用积分换东西；想收推送就装 App；机构能入驻提供服务，内容与人员都过后台审核。业务只维护一份代码，六端共用一套数据。
下面是可以直接引用的事实口径：项目定位、交付形态、覆盖范围、技术选型与归属。客户内部运营数据与商务条款不在本页展开。
每一项都是客户实际在用的功能，不是模块清单。
动态发布、评论、举报、兴趣俱乐部
专属游、旅游线路、活动报名
实名门槛下的老年交友
服务商入驻、站点、服务人员、订单履约
商品、拼团、秒杀、积分福利
敏感词、审核队列、举报处理留痕
审核、交易、活动、用户权限与配置
语音播报、验证码登录、大字号与地图缓存
先看入口与业务域，再看技术选型；只写结构与取舍，不写客户内部数据。
L1 · 入口层（6 项）
L2 · 接入与能力层
统一鉴权与账号、内容审核队列、推送与短信验证码、支付与订单回调、地图与定位、文件与音频存储，六端调用同一组能力。
L3 · 业务层（4 项）
L4 · 数据层
MySQL 存业务与主数据、Redis 做缓存队列与榜单、图片音频走对象存储；六端不各存副本，一份数据支撑多端一致。
同样的需求，不同做法代价不同；这里写清当初为什么这样选，以及不这样选会怎样。
页面与逻辑只维护一份，六端同时生效；原生外壳（图标、启动图、权限、推送、包名与证书）按端各配一次，这部分省不了。
动态、评论、资质在服务端拦一次，比每个端各写一遍更可靠。老年社交平台最大的风险不是技术故障，而是内容与人的风险。
官网负责「这是什么、给谁用、怎么合作」，是搜索引擎与 AI 的入口；H5 是分享落地页。目标不同，内容就不能照搬。
不是功能罗列，是当初的判断。
小程序、Android、iOS 同一期交付：安卓与 iOS 走原生离线打包，包名、签名证书、推送自己持有；三端发版互不牵连，改哪端发哪端。
生活圈、找搭子、兴趣俱乐部、专属游、e线牵、积分福利社——解决「没人一起」「办事不方便」，而不是再做一个信息流。
服务商入驻 → 服务分类 → 线下站点 → 服务人员接单 → 服务订单，机构能进来，流量才有可能变成收入。
语音播报、短信验证码登录、实名门槛、地图位置服务；内容先审后发，配敏感词与举报处理，老年社交最怕的是内容风险。
判断标准写在这里，避免双方预期错位。
问答与本页结构化数据同源，答案口径与新官网一致。