没有啊，我用Win8.1+Chrome V38+搜狗，输入神马的一切正常。好久以前——不记得是否是V2x.x的时候的Chrome偶尔会出现这个问题，现在基本没有了。

@hifengthis 从产品展示图片来看，站立时，要么手肘低于键盘水平线，要么显示器位置太低需要低头，还是不太理想。 要达到知乎帖子里的那种状态就最好了！

@line 感谢提供。这个价位，性价比挺高。但是，该产品作为站立式台面使用时，要么显示器位置太低，要么键盘位置太高，桌面下补充一个可拉伸的键盘/鼠标托盘是极好的。另外，不适合我的就是公司已有办公桌，且办公区域狭窄。 但这款产品对于家庭用户使用应该挺好的！

@xcv58 好一点的支架也比“好一点”的椅子便宜好多，哈哈，当然我不是说站立办公就是解决办公室亚健康的银弹了，whatever站or立，劳逸结合是原则，适当运动才好！ 另外，高脚凳我认为也还是要配备的。

所以，我现在的目标是：
1、VESA标准显示器万向支架，可上下调节，考虑是否双显示器还是显示器加笔记本
2、宜家小板凳桌放键盘鼠标，比键盘+掌托稍宽，长度比最长全键键盘长10cm即可（我喜欢高DPI鼠标，活动范围小）
3、高脚凳，用做短暂休息

自问自答：搜了达宝利的产品，我发现我最需要的其实只是能上下调整的显示器支架——因为显示器大而笨重且有线，不好搬来搬去和上下调整，牵一发而动全身。相比之下，键盘和鼠标都是无线，轻飘飘的，大不了自己去宜家买个小板凳桌呗！所以关键点就是显示器支架了。为自己点个赞，哈哈！

我想我大概已经找到我要的，只是这价格太惊悚了，有淘宝替代款吗？
http://item.jd.com/1035842009.html

@jamiesun 膝盖就还好，长期久站其实会导致静脉曲张，比如以前的老师、公交车售票员等等职业。详情可见知乎讨论“站立式办公和使用人体工程学座椅，哪种更有益于健康？”： http://www.zhihu.com/question/21679072

@caiych 交替是肯定的，但我干了这么多年，颈椎、手腕、视力都保护的还行——关键是显示器高度调整到位、左右手交换使用鼠标、工作一段时间就走动休息、多喝水和上厕所——只是因为课外运动少，久坐成肥，所以才想站立式办公。 现在也用的是番茄工作法，精力更集中，休息也更彻底了……

@F2Sky ，感觉就像是你又把唾沫星子喷到我连上了，啊哈哈哈 23333333333

掌握C++的语法不是大问题，大问题是一旦不参与实际项目，很难获得深入提高——当然，自己一个人练习做个小软件也是可以的，但桌面C/S系编程对比Web B/S系，反差是有一些的，看个人觉悟了。

另外，指针（内存管理）一直是C++的强项并且也是“阿克琉斯之踵”，要深刻体会！

ps：对于C艹（C cao）的这种表示法，也是感觉到醉了，这是有多恨它吗？

转发到一个Gmail邮箱集中处理是王道，想不同账号发邮件Gmail也支持，就是个搜索能力强大、不占本地空间的好东东，已用好多年。离线的话，手机可以顶一顶。

@qping maven配合jenkins估计也解决不了你的问题。
我觉得你需要的是一个程序（Ant？Java？Python？）来帮你处理编译后文件的更新问题，大致流程如下：
1、下载和解压目标WAR文件到某个文件夹，这个WAR文件也就是你已经发布到产品服务器上的那个，本质都是zip格式，你懂的
2、查找文件更新：给定一个日期（上次发布的日期？），通过该日期比对源文件的最后更新日期（SVN？本地？），决定是否将该源文件对应的class文件或jsp、js等复制到目标WAR文件夹（假定已经完成编译和其他资源处理）
3、重新压缩WAR文件夹为WAR文件
4、你最好还是基于Branch来，否则在Trunk中有些不必要的文件更新也会纳入进来

—————————————————————分割线——————————————————
说回Maven+Jenkins，我理解你们的处境，别说1G，就算是几十兆的包我都容忍不了，呵呵。
我采取的办法是在生产环境（不一定是服务器，可以是自己的机器或者客户方提供的部署用的机器），使用楼上提到的Maven+Jenkins（当时还叫Hudson），SVN不在生产环境本地都没有关系，只要能联网更新，进行编译、打包，最终的war包要么自动发布上去，要么手工ftp上去，要么U盘copy上去…… 第一次会比较慢，因为要更新所有的源代码并编译，还要下载jar包…… 当然，你可以预先把一个本地的Maven Repository复制到Jenkins服务器上！

总之，不要人工去更新那些war包。

如果你们没有用Maven，用Ant也是可以的，如果你们连Ant都没有用，那就从Maven开始重构吧！

不太明白这个增量包是个什么东东？ 一堆更新了的java class？jsp？

但是SVN是有branch特性的。一般的做法是：基于当前的Trunk版本，可以为将来某天发布、具备某些特性、修复某些bug创建一个branch（其实就是另一个代码库），程序员对这个branch的代码进行更新，测试人员也基于这个branch进行测试。达到要求后，使用branch中的代码进行编译、全新发布；发布成功，将branch中的变更merge回Trunk，Trunk继续成为下一个branch的基线代码库。 merge这个动作都是基于源代码的，而且都要求哪个程序员改动的，哪个就负责merge回Trunk库，遇到多个程序员修改同一部分代码，要求他们内部协调，一般都不会有太大的代码冲突。

如果你的增量包就是我理解的那样，的确工作量大而且容易出错，配置管理形同虚设！请牢记：配置管理应该主要基于源代码（不是绝对，但应该是绝大多数），而非编译后的目标文件。