@MasterYoda 任意键位都可能出现这个问题 总不可能全部都给你换轴吧。。。
另外两块都有这种问题。。我不会脸黑到两个都买到次品吧。。。

@GhostEX 连击的情况不是出现在单一一个键位上，任意键位都可能出现这个问题，因此我才怀疑不是物理因素原因而是无线干扰。。。

activemq/rabbitmq 是 AMPQ 的具体实现——你可以理解成 nginx 、 apache 、 lighthttpd 、 tomcat 等服务器是 http 协议的具体实现

jms 是 java 消息队列的标准——你可以理解成 Servlet Api 是 java web 开发里与 http 请求、响应交互的标准接口

@anewg 。。。。。。洛阳铲

[
{
"input":{
"type":"text",
"name":"some-name",
"id":"some-id",
"placeHolder":"xxxx",
"valid-expr":"正则表达校验"
"value":"xxxxxxx"
}
},
{
"input":{
"type":"text",
"name":"some-name2",
"id":"some-id2",
"placeHolder":"xxxx",
"valid-expr":"正则表达校验"
"value":"xxxxxxx"
}
}
]


类似这样的，自己写成 json ，然后前端 js 自己解析下就好了。不是什么很难的东西，不需要因为解决单个这样的需求而引入一堆不必要的类

@Wowbeing 昨天缺货的书今天全部上架了，看来我真是在“无脑黑”呢

@vietor 不是每个人都像你一样，也别把每个人都想成像你自己一样

@hljjhb 你好我来打你脸了，现在是 11 月 3 日 00:20 ，京东商城图书又全部上架了。呵呵

@x86 CoreOS 表示笑看你们这些渣渣

CoreOS 的版本号是以发布日距离项目初始发布日的天数来算的

大兄弟搞基吗

@inevermore 非常感谢！

@register 谢谢，其实主要这里是我没有找到一个合适的说明方式。
准确的说应该是 tcp 是流协议，其中一个 packet 数据出错可能会影响后续的 packet 数据。。

@xierch 你这样的回答对别人一点帮助也没，反而也是在浪费自己的打字时间

@hyq 我现在的协议类似 http ，有 header （定长）和 body （变长）两部分， header 里带了 timestamp 、 body 的 length 、 body 的 checksum ，然后根据 length 去取剩余变长的 body 部分。
现在主要是怕因为客户端乱来等原因， body 部分丢了一半，但是服务端解析的时候为了读取 body ，会把下一个协议消息包当成当前 body 给读进去，导致后边所有的包全乱了。

因此我想解决的是如何比较优雅的处理当前异常消息包而尽量减少对后边消息的影响

@morethansean 就怕有异常。

@sujin190 你好，除了重新打开客户端链接还有什么其他更好的办法吗？

我申诉了好几次，然后成功了

又一个被终端过度毒害的人。

没有任何意义浪费时间的瞎折腾。

markdown service 这个，其实 markdownToHtml 可以独立放在一个 Util 类中做静态方法的。