确实，音乐会存储人的记忆。有时候直接回忆某个时候的事情很难，却是在当年的音乐能让人瞬间想起某一刻的时光。

正常逻辑肯定是数据库直接搞定。

ACTFramework

看了一圈没看到汗蒸。
其实韩式汗蒸很不错，我们之前一直去那团建，泡个澡出来聊天打牌、看电影打游戏、游泳等等。不想参与集体活动自己躺那睡，很自在，里面还有各种好吃的。可以待一天。

每年都续，家有幼崽，吃的喝的都从山姆采购。

苏州欢迎你

通配置没有发烫，你看看是不是 CPU 占的高了

@loveyou1 可能聊岔了，微信除了自己调起收银台等内部请求可能是基于微信浏览器内核搞的，大部分都是可以通过 SDK/HTTPS 请求的，包括支付回调（微信主动请求你的服务器）都是暴露出来的。大体逻辑就是生签&验签，可以具体看看： https://pay.weixin.qq.com/wiki/doc/apiv3/wechatpay/wechatpay4_0.shtml

@loveyou1 拦截是可以...不是讨论怎么防止伪装请求吗？

做过微信支付吗？看看微信如何防止伪装请求的。

我朋友：我要是老了靠交社保的养老金，那我这辈子就完了。
我：......

@madlifer
关于真正的社交部分交给用户当面去聊这点我有点疑虑。如果是陌生人社交，我认为你说的做法应该是合适的，但作为相亲场景，是不是来的太慢了。

在我的认知里面相亲在进入到亲密关系之前，是一个很类似“交易”的东西，如果接下来才发现不合适，对用户的挫败感会很强。
--------------------
没错，我顺着你的话说着说着忘了补充背景了，刚刚那段表述确实是针对 [陌生人社交] ，而非 [相亲场景] 。关于 [相亲场景] 我也仔细想过，还是有个坎过不去，包括现在市面上的那些恋爱相亲产品。假设产品对资料背景匹配的相当好了，过了 [资料交易] 阶段，逻辑上对用户算是有个基本交代，后续该怎么进行？很多男用户会担心付费解锁联系方式就是被骗被收割；双方在线交流也会是一个问题（会把天聊死，或者变相查户口等等）；加上无良产品搞那么多的女性机器人故意收割会员费，想想都头疼。所以如果还是同样逻辑做相亲产品，我觉得很难走出来。用户可能已经对这类产品定性了，改变难度很大。

我理想中的陌生人社交产品从工具层面出发，在做好引导的基础上只把双方的信任及安全问题解决，实际的社交问题交给用户见面发挥。能让用户觉得这是一款认真的产品，并且不是设卡收费（比如要微信要付费、要电话要付费、要看照片要付费等）的产品。

关于社交那段我蛮赞同你的 [严肃性] 观点，现在提到陌生人社交很多人都觉得不靠谱。 [匹配逻辑] 那段实现难度太大了，要知道让用户填入那么多信息就已经很难了。我个人对于社交产品，特别是有匹配逻辑的产品的匹配逻辑是越简单越好，我倒是觉得如果把产品做成破冰工具，怎么让两个人见面坐下来，真正的社交部分（如家庭背景，经济情况等等）交给用户当面去聊，而非交给产品。我在做这方面产品尝试，有兴趣可以深入探讨一下。

文章写的挺好的，期待后期系列，希望不要断更 doge 。

能具体说说吗？

把工作搞好了，正大光明摸不好？
不知道有没有 BOSS 看到这种帖子。

TDMQ