我买的无刻的，刚开始也不太习惯，用多了就好了。不喜欢用机械键盘写代码，怕吵到别人，写久了手酸。薄膜键盘和 macbook 自带的手感就更差了。
其实主要是有洁癖，不想让别人碰我的键盘，甚至领导看我的眼神都不一样了。
https://www.v2ex.com/i/21nO1NV3.jpeg

@awanganddong

我之前也做过类似的需求，基本思路差不多，对搜索接口做了一点优化：

1. 异步删除帖子：用户被封禁时，通过 MQ 发送一条包含用户 ID 的消息，然后消费者异步删除 es 中的 docs
2. 搜索接口优化：搜索到结果后，可能存在某一个帖子还没来得及删，所以需要判断用户是否被封禁（可以通过查数据库、查用户缓存、bitmap 等方式）。如果用户被封禁，将该帖子数据简化，并标记为已封禁，然后返回给客户端。让客户端展示一个被封禁的文案（也可以直接过滤掉该条帖子，看具体需求）

由于 es 的 doc 是不可变的，所以最好不要做更新处理。更新操作实际上是通过一个.del 文件将原来的 doc 标记为逻辑删除，然后再新建一个 doc 。

真是令人唏嘘

帮顶（可惜没有后端）

没示例代码吗？应该是切面实现的问题

晒干了沉默

1. 前端维护一份 code -> description 的映射。缺点：需求变动可能要改代码重新发布。
2. 后端返回列表结果的时候把 description 直接带上。缺点：报文变大。
3. 后端提供一个查询接口，返回 code -> description 的映射，前端缓存。缺点：增加前端复杂度。

@awanganddong 是要在搜索结果中把被封的用户的帖子都过滤掉吗？

社保没交直接离职呗， 背调查不到这段经历。

如果是正版不推荐，已经是一片红海了。
如果是盗版也不推荐，会被各大厂轮流告。
如果是那种就更不推荐了，会蹲大牢。

我现在写笔记用：自己域名 + Github Pages + Markdown + Docsify
如果希望提升国内访问速度可以用 CDN 全站加速，或者把静态文件放到国内的云文件服务。

参考： https://notes.leego.io/

响应的结果还是 JSON ，提升不了多少。既然都打算压缩了，不如前后端约定好一个协议，用非结构化的报文，不然没什么意义。

微信封号一直很严格，好几年前用模拟器就会被封号了。另外，修改客户端文件，进程 DLL 注入都是有概率被封号的。

可以考虑基于 Windows UIA 实现自动化，没风险：
https://github.com/yihleego/robotic-process-automation

https://i.v2ex.co/aiRkp4B2.png

1. Settings 中选择一个数据源
2. 对 @Select @Insert @Update 等注解设置 inject language 就可以了

受限于 Go 语言本身，注定就没有好用的 ORM 框架

无论是开发 Carbon 的动机，还是 Carbon 本身的语法，都有一股浓浓的逆反味道。

netty