现在的拼音输入法都是一个妥协措施，拼音本身都不成熟，你还想让他往编程语言上搞。

读音和文字是两码事，英语变成用的是文字而不是读音，换成汉语变成也得是文字，不能是拼音。

@winterbells 你就是告上法庭也没用，暴雪游戏的用户协议中都会有这么一条：您的账号、游戏中产生的所有数据，所有权都归暴雪所有（请注意是暴雪而不是网易，当初九城被零成本取消代理权，这个是关键）。别说被举报封号了，就算天灾人祸把数据丢了，你也只能干瞪眼。

凡是底层 unicode 的，变量名、方法名这种名称性的东西，都可以用中文，以及任何 unicode 范围内的文字。

java 最晚 1.4 版本的时候，就支持中文变量名。但是编码规范第一条就是：不要用中文。

我现在 junit 方法名，当分支方法特别多，用英文方法名又长又不直观的时候，回用中文方法名。

作为一个风暴英雄第三次被冻结 30 天的人，我可以很明确的告诉你：举报是冻结的必要非充分条件，撞到审核人员枪口上或者影响到网易赚钱（为了照顾玩家情绪，隔一段时间严打一次），才是冻结的充分条件。玩网易（以及一切网游运营商）的游戏，切记：绝对不能投入感情，非必要时刻永不投入金钱。

不要去询问为什么被冻结，我前十几次的冻结，给的原因都是“怀疑被盗号”。那段时间，只要凌晨玩并且稍微有挂机行为，凌晨 5 点必定被冻结。凌晨 5 点冻结账号，不是晚上玩游戏的审核人员干得，你信吗？

另外，网易明确的告诉了所有玩家，一切申诉，都不可能提前结束临时冻结。

再另外，被冻结几十次，但从来没有封号，基本可以说明，“临时冻结”等同于“警告”，就是告诉你老实点。正效果是有点的，以前用特殊英雄挂机，现在人工挂机。反效果是很大的，17 年 3 月前消费一千多，之后至今消费不足 50 ；以前当主力游戏，现在当备胎。

@wangxiaoaer
前端想要稍微复杂一点的查询，就要自己写 HQL 语句，然而 HQL 语句是纯后端的。

深入一点的说，那个框架只是把领域模型中的实体暴漏成了 RESTFul 资源，整个框架，只处理实体，然而实体并不是后端的全部（虽然它是核心）。贫血领域模型至少还需要 Service 层（处理后端业务）和 Web 层（转换前后端参数）。常规领域模型则需要应用服务（转换前后端参数），领域服务（处理复杂业务），领域事件（解耦）。

说句实话，如果后端只是对数据库的增删改查，还不如不要后端，前端直接操作数据库（最多为了安全添加一个数据库的代理服务器）。

以前碰到过，但是是别人公司内部用的，貌似是基于 Play 框架再开发的。
给了 UML 类图，后端接口就自己全部生成了。

当然，前端被坑惨了。

楼主只有一个选择，去手机店体验。

现在想用一个机器来回刷 windows、mac、linux 的难度都很大，手机上互刷系统就别想了。你说的这四家，自家的系统随便刷（前提是硬件允许），别家的系统别想刷。BootLoader 层的代码是不兼容的，就算兼容，你给你人工加锁。

手机卖给你才赚了 5%的硬件方面的利润，后面整准备狠宰呢，你要是刷了别人的系统还怎么宰？

移动以前的校园优惠，是有基站范围的，只有在学校基站范围内的才有优惠。楼主能确定这个没有范围吗？

该按钮怎么处理，完全是 UI 自己管的事，Restfu 接口设计时完全不用考虑该按钮要干啥。它需要考虑的是：购物车资源，应该暴漏一个结算行为供远程调用，所以 Restful 接口提供的资源是“购物车 /{id}/结算”。（“资源 /动词”表示资源的某个行为，是合法的 restful 风格）（相应的，UI 那里也只需要调用一下这个接口就可以，它完全不用考虑后续的业务是怎么处理的）

至于 restful 接口之后的过程，就要涉及到领域模型相关的知识了，这个一时半会说不清楚。大致提一下过程（ restful 接口只需要调用购物车的结算方法，不用关心后续过程）：
购物车：结算
——》结算事件：被发布
——》新建订单监听：处理结算事件
——》订单：被创建
——》订单创建事件：被发布
——》
[并行] 用户相关监听：处理新订单事件——》用户 /用户余额：减余额
[并行] 物流相关监听：处理新订单事件——》物流：新增
[并行] 更多相关监听

有一个非常重要的点是：要使用 restful 接口，必须要一起使用领域模型设计，而且是启用了领域事件、异步、最终一致性的 DDD。如果还是传统的纯事件驱动模型设计（界面点个按钮，后面巴拉巴拉怎么处理），就不要用 restful 接口，强行使用（比如说动词名词化），很 S B。

用户需求、UI 对象、Restful 资源（可以理解为远程接口资源）、业务对象、数据库表，这几个中，任意两个之间都是不一样的，任何试图将它们进行一一映射的措施都必定会失败，任何试图将它们进行一一映射的想法必然是 S B 的。

按钮「去结算」是 UI 对象“某个按钮”。

@TuringGunner go 不是做后端的，曾经特意搜索过 go 的定位，它是用来替换 C 的，倾向于系统层，而前端、后端都是偏向于应用层的。

http://blog.jobbole.com/114009/
无分布式的，建议用 HashTimeWheelTimer
分布式情况下，先用 redis，复杂了再用 rabbitmq 方式。

但是你这个三个小时生效，时间间隔长，又规律的（可以认为限制只能整点生效），就没必要延时任务了，直接定时任务没半小时跑一次就行。

这玩意取决于老项目是怎么用 Hibernate 的，它如果只用来当 ORM，那么切换到 Mybatis，没有任何难度（可能有以下自动代码，需要手工再补上）。如果不止是 ORM，还用了 @Repository 的概念，那么切换到 Mybatis，等于重做系统。

仔细看了楼主的问题，貌似是 Mybatis 到 Hibernate，而且不是 ORM 切换，是功能复制。这样的话，基本不存在可重用的轮子，必须重造。只有用户表的话，估计原来也不会做 SQL 优化，使用 Hibernate 重造，完全不用担心可行性和难度，但是复杂度和工作量就不好说了，取决于你原来的数据库设计是否合理（合理性是参照数据库设计原则，与 Mabatis 无关），和你对 Hibernate 的理解程度