先让前端的开发自己验证 history 模式没有问题；再把 index.html 放到 java 后台渲染。

很多早些年的读音现在都改了，改成大众经常读的了

@bobawujh 看了大家回复才知道原来日本 19 年税涨到 10%了； 19 年之前每年都去，疫情之后就没去过了；国内现在也不是 17%而是 13%了；所以现在差价不算高了
@Y29tL2gwd2Fy 游客是在固定的消费额度范围之内没有税吧，记不大清了；我先前去是因为经常去就弄了个工作签，所以不享受游客免税

Reminder 或 Calender 就可以实现吧

日本电子产品是 8%的税吧记得是，国内是 17%

确实，左边的新 logo 好看多了

呃，其实可以用 Numbers 就够了

如果这个标题是"请问在北京这个城市工作和生活体验如何"，回复差别有多大？

楼主你把号借给我就可以了

我和老婆，她做饭，我洗碗

Karabiner Elements

现在的两套有贷款么？没有贷款能不能抵押贷款先？

重度命令行用户，目前还是用 iTerm2 ； 内置 terminal 功能还是有些少，比如横向纵向分屏和各种快捷键

我买的几本书也等了一个星期今天才到

@falcon05 暴露年龄了，XD

@Canon1014 性能问题不大，比如用户服务完全可以把根据 id 查的接口通过一系列手段如缓存优化到极致；实际应用中排行榜服务还可以使用并行调用、本地缓存等手段进一步提升获取数据的性能

业界各种方案都有用的；以排行榜服务和用户服务为例：

1. 客户端自己根据 user_id 再查，这样排行榜业务不需要依赖和调用用户服务；不过这种如果追求极致的客户端体验的话可能不会用，毕竟如果数据查询多客户端查会体验差
2. 排行榜微服务接口在接口层依赖用户服务，调用用户服务接口，封装到排行榜接口之后返回；（微服务的一大优势就是用户服务可以把相关接口优化到极致，即使服务器端同步调用性能也够）
3. 排行榜和用户服务之上再来个胶水层，专门做数据组装，常用 nodejs 之类的做
4. 还有一种也是微服务中常用的，冗余；比如排行榜可以把自己依赖的用户名做一份冗余存到自己数据库中；但是此时要注意和用户服务的同步问题；一种做法是不敏感的数据本地缓存定时更新；另外更标准的做法是使用消息队列来监听用户服务发布的事件做本地实时更新

@Canon1014