@yangyaofei #11 "刹车根据踩踏行程，分配动能回收和刹车比例", 所以就是其实技术上是可以做到的. 谢谢

@opengps #10 我的意思是保持比较轻的刹车的时候, 动能回收. 不是遇到紧急情况需要快速减速的场景.

@billlee #8 看网友的说法, 发动机制动应该减速效果没这个强. 不过我没对比过.

@kop1989 #6 "电制动和物理制动的匹配问题" 是说要结合电制动和物理制动这两个制动方式, 协调工作比较有难度的意思吗?

@263 #1 你这混动吧? 没啥不好意思的, 我没开过混动. 你也别不好意思

"会不会和同事的关系发生疏远"
会. 所以要定期沟通; 及时给同事反馈.


远程比坐班的优点多多, 所以我觉得这点劣势没啥, 不会让人焦虑.

如果这个程序运行时你自己不操作鼠标键盘, 游戏可以窗口化, 那么可以用 uipath 这个图形化编程的自动化工具

https://www.uipath.com

截取程序, OCR, 发邮件的功能都有. 我的经验觉得可行.

我的理解, 这不是语言的约定.

JS 事件比较多, 一般事件的接口 onSomeEvent 比较好理解, 因为定义接口的时候, 事件要怎么被处理是未知的;
如果这个接口是一种能力, 比如接口是 Printable, 那么接口方法用行为 print()比较好理解

@aec4d
@psx2019 感谢. 我自己的方案是会用 kafka. 只是毕竟自己要实现消息的过滤和路由等, 想找找看有没有开源的成熟方案.

我倾向于一个表一个 api, 每个 api 都支持限定字段查询, 限定返回字段
/<API-Name> 返回所有数据的所有字段
/<API-Name>?<FIELD1>=xxx&<FIELD2>=yyy 返回部分数据的所有字段
/<API-Name>?<FIELD1>=xxx&<FIELD2>=yyy&fields=<FIELD3>,<FIELD4> 返回部分数据, 且只返回 3,4 两个字段

这里做 3 个 api
/device
/user
/device_with_user: 这个会内调 /device 和 /user, 然后 join 数据

如果“清空并重新计算指定产品的购买限制” 是实际需求, 而"删除指定产品的全部用户的购买记录"只是你想的实现方法的话, 我觉得没必要删除购买记录 key.

新增一个 key "product_reset_<product_id>", value 存重置的时间. service 这边可以定时更新(比如每 5 分钟)这个数据存在内存里面, 因为这个行为应该是运营有计划的, 所以可以要求(或者告之)他们至少要提前 10 分钟在系统设置重置.

用户购买记录, key "product_buy_<product_id>_<user_id>", value 存 购买时间,数量, ... , 购买时间,数量, 每次购买刷新过期时间为 24 小时


用户购买时, 读其购买记录, 并过滤时间早于重置时间的数量, 然后计算是否可以购买, 能购买几个

同意一楼, 这个要看自己的风险承受能力.
就我而言, 我会保留一年的开支等额的现金(活期, 余额宝等)，应对走背运情况下不会断供.

再补充一下, 其实以前有不少小区相关的网上社区, 然后都被 qq 群, 微信群干掉了.

这些都是低频需求, 所以你做个小程序或者 app 别人也不会来.
加个小区的微信群, 这些都有了. 比如我们小区有业主群 3 个, 足球群两个, 司机 /拼车群一个,二手交易群一个,物业问题群一个,楼群一个, 还有很多买菜, 买家电, 王者荣耀群...

你要说在拼车群里面拼车肯定没有一个单独的 app 方便, 但是群里面可以聊天不是?

不尽如人意才是生活的常态, 不是吗?

还是需要对每个用户存储其看过的视频, 但是每个 id 都记不合适.

大部分情况下, 给用户展示的视频是按 id 排序的, 少部分是随机的(精选).

记录的 id 也分两种形式, 比如 [1, 30], [40, 48], {51, 72, 99} 表示看过 1~30, 40~48, 以及 51, 72, 99.

那么当下要推荐给用户的视频, 应该是优先推荐精选, 然后就是以缩短上面的记录为原则.

比如今天的精选是 {200, 210, 22}, 然后首页需要 5 个视频, 那么再补上 49, 50 比较好.
sql 就是 select id in [200, 210, 22, 49, 50]

这样新的记录变成 [1, 30], [40, 51], {72, 99, 200, 210}

@cian 车停下, 想上车。全栈，都会点.

非常感谢!