c#吧，学着玩的话，这东西上手很快，IDE 强大无比，文档很全，普及率不如 java，但是好歹也是微软家的亲儿子，各种特性都十分主流，很多语法糖能做到领先 java 半代。但是学习曲线吧，后期会很陡峭，难度并不比 java 小。

@ericls Web 慢，这个结论，并没有什么不妥啊，你看原生的资源都在本地，Web 的资源都在远端，加载不要时间？
另外，在上面说的那种促销活动的场景下，Web 资源是几乎不太可能命中缓存的（其他场景需要单独分析），对吧？但是呢，作为 webview 或多或少还是会“自作主张”去弄一些本地缓存的，对吧！多出来的这些“无用” IO 操作难道不消耗性能？

@starcraft 永中 Office 表示在用户体验上无限接近（抄袭） M$ office 的哦！当然，那玩意不开源，只是免费的而已

企鹅如果想上传，真没有必要开一个新进程，对吧

没发现哪里能买到

试试永中吧，你不会失望的

@he583899772 不排除还有用 get 方式操作数据资源的情况，比如写一个类似这样的玩意，诱导用户打开:
<img src="http://一个域名 /page.php?Buy=11&Count=10&money=1000">
而假设此时用户的 Session 是合法的，于是。。。

XSS 吧
简单来说，比如我在某论坛里发帖子，帖子正文写这样的东西:
<script>alert("本论坛即将于某年月日关闭，请及时保存数据迁移到 XXX 论坛");</script>
如果不做任何处理的话，在别人浏览的时候，吼吼~~~~

To 楼主，关于老大让你自行解决的这个问题，我支持发现问题的人自行处理。理由如下：
1、谁开发的 bug，谁负责。这没错。但是谁开发的 bug 谁去修就不一定对了。代码是团队成员公有的，原开发者可以比别人做得更快一点上手（假设他自己没忘记的话），你发现了不能编译，在第一时间改一个能编译运行的，即使只是为了你自己调试也是有必要的操作，没必要等挖坑的人，这会浪费全团队的时间。
2、既然有人挖坑了，你还愿意信任这个挖坑的家伙填坑会填的很好么？遇上猪队友，还是万事靠自己！

但是并不是说一定要完美解决，留下注释，打好 todo，比如：// todo 修复 12345 号签入无法编译通过的问题，功能未测试 @某某某 浪费团队成员时间 2 小时于此！
连同注释和修改一并签入，并邮件抄送团队全员，确保责任明确

@Daming 然并卵，我这里有一瓶 1982 年的拉菲，额，不，一个 1982 年的程序猿，做了一周，只提交了 3 次代码。其中第一次无法编译通过，后面两次无法运行通过。经过 code review，所有代码都被我给回滚了。也就是说，一周工作量是负数（消耗了 code rerevie 和回滚重写）

maxgear 2201(14 寸电脑包，仿 magforce 2201 的)
magforce 0513(军规 3P 双肩)

@abcbuzhiming 在有多层的架构下，每一层都是可以单独做缓存的，每一层也都可以单独做数据持久化。比如我们的一个项目，在消息队列持久化的地方用了 ravenDB，在 UI 层用了 mongoDB，当然在数据访问层必然也是有缓存的，所以 sql 的压力并不一定会大到不可接受的程度。另外，sql 服务器是要做群集、镜像的，读写分离妥妥的好吧（注：我们不是用 java 写的）。至于强一致性吧，sql server 是可以支持 [跨库事务] 的啊，没觉得有什么问题，mysql 不熟，应该有类似的功能吧？

@l00t 最小环境搭建的话，那不就是一台开发环境吗？莫非 java 项目有什么与众不同的问题？我手里有个规格比这个大一倍以上的玩意（不过不是 java 做的）在一台服务器上跑的好好的，哦，实际上还不是一台物理服务器，只是 Dell 服务器里的一个虚拟机上跑，并没用到整机。和这个项目不同，大量中间件、组件、服务用的是商业平台，而不是开源的，数据库是 sql 2012，消息队列是微软 MSMQ，缓存是 memcached、RavenDB

接楼上 #8 楼我自己，勘误
这种设计 [是不是] 可以很轻松地增加服务器的 [数量？对吧！]

答复楼主，这种结构很正常（虽然我不是做 java 的）
to #1 卡到爆，你确定？这种设计不是可以很轻松地增加服务器的数量，对不？举例：业务旺季（如，双 11 ）期间多加两倍的云主机进去好像很合理，对吧
to #3 和上面说的刚好相反，接上述示例，淡季减少服务器数量即可省钱。另外，抠门的话全都堆在一台服务器上似乎没什么不妥。

@ivanchou 黄牛用的囤票的身份证啊，黄牛怎么会去取票

黄牛用大量身份证囤票，有人买的话，就在代售点，准备好抢票软件和用户的身份证号使劲刷新，然后发起退票。时间点足够快的话，大概率就买到了

如果使用某些重构工具\插件的情况下，显式声明会更安全，因为工具不一定能准确识别 this 还是 base，甚至继承好几层的情况下 base 都不足以表达了，你敢不加前缀？