wdytoya

也不用说现在，其实我在 15 年去过一次，去年又去过一次，去年去的那次就已经发现不单单是鼓浪屿，中山路上也有好多 15 年去的时候还在的店都关门了。本身疫情对于旅游业甚至服务业的打击就是巨大的，所以在 20 年之后，能活下来的本身就是有良好的抗风险壁垒的店了。其实也不用刻意强调什么时候去是最好的时机，在现在疫情长期局势仍不明朗的情况下，及时行乐反而是当下的局部最优解

参加过不同类型的年会哦，要我说印象深刻的肯定是员工有参与感的，但有参与感有的时候并不是很乐意的而是被迫的，所以我个人观点
1. 不要搞什么节目了，当然如果领导们愿意自己出节点给一线看也可以
2. 但要让员工有参与感，要么就是松散的比如轰叭馆让大家自选自乐，要么聚在一起搞晚会的话就搞几个小游戏抽几个人上来玩玩就行
3. 抽奖+发钱
4. 最后如果你们愿意可以让领导们分享分享新年业务规划，不用太久，就是纯聊天缓和一下气氛，员工爱听不听也没啥影响的那种

作为后端同学来说一下我的想法，仅供讨论

其实你说的 12 两种方案都可以，我这都用过，具体用哪种方案取决于你具体的业务场景
1 方案的核心含义在于一次性返回全量数据，优势自然是减少前端请求次数，也相应减少多次网络上的开销，但劣势也很明显，因为你需要聚合完所有数据才能渲染，如果数据量较多，耗时较长，在用户 C 端上的体验就很糟糕，会有长时间的白屏，即便有些业务用 loading 态或者骨架图来兜底体验也不会好到哪去
2 方案的核心含义在于按需索取，优势在于你可以先渲染核心数据，非核心的数据增量渲染，特别是在一些动静分离的页面设计上是很有优势的。劣势自然就是增加了前端的请求次数，增加了网络开销和网络抖动可能导致的异常几率

而像楼主附言所说的两个页面，一个是订单列表页，一个是订单详情页
针对订单列表页，其实核心展示信息不多，主要是商品图标、商品名、订单 ID 、订单状态，其实是没必要返回商品全量信息的，所以如果按你们现在的方案 2 的设计去调一个批量接口或者分页接口是没毛病的
针对订单详情页，由于一般都是纯静态数据，而且用户不需要太多的行动点，这时候确实是可以一次性返回订单全量信息的，所以用类似于方案 1 的接口设计就会更合适

最后再说一下楼主说的刷 token ，这个楼主没理解为什么需要前端刷，其实楼主如果是 PC 时代过来的前端可能就不会很难理解了，一些文档编辑框页面的刷新就是一个经典的例子。因为页面是静态的，用户一直停留在页面上后端是不知道的，只有前端自己知道，而如果前端不去定期刷新状态，那么就会出现一种情况，用户在 token 过期之后在页面上执行了某个提交操作，结果由于 token 过期无法提交，可能在你第二时间才去做刷新操作之后，用户可能页面上填写的东西没保存下来就没了，那用户体验也是很糟糕的，当然有些做法是可以保存页面填写内容的，那为什么不直接就在过期的时候就提醒他要主动刷新了呢？
当然这里面还是可以说取决于你具体的业务场景，因此如果你们的产品对于第二时间再去做强制刷新觉得没有大问题，那也可以不用前端定期 refresh ，主要还是看第二时间的强制 refresh 会不会存在打断用户主流程的问题来决定

你这哪叫难，只是款式的话随便多逛一逛基本上能找到差不多的，只不过可能不是大品牌，但你只要看出产地是南方某市基本上质量问题也不大
真正难的是要么没尺码，要么一些功能鞋就没几家生产的，比如你需要指定面料的

@im67 那是刀区一哥 ban 的，也不是 LGD ban 的（狗头）

其实他们催几年催不动就会慢慢不怎么催了，心愿就会变成你健康就好，但偶尔还是会说找个人互相照顾
这种就是多交流多沟通就行