订单列表里面的用户名就是个伪需求。业务部门关心具体某个订单是阿猫还是阿狗？

好吧，真有这种需求的话，聚合查询才是正道。

因为真正执行 Console.Write($"{i} ");不是在 for 循环里面，而是在 foreach 迭代里面呀。

难道还有名实相副的旅游景点？？？不如把问题换成：哪些景点值得一去。

好厉害的喵喵(≧∇≦)ﾉ

这个叫类型推断，不是没有数据类型好吧。var a = new String();变量 a 难道就不是 String 类型了？编译器能够从 new String()得到 a 的类型，不需要你特意指定 a 的类型而已。

idea 有个插件，可以把类型隐藏掉，然后显示为 var……

@ebony0319 这种大多是群控搞的，就是有几万台设备，一个设备上有若干账号，然后通过群控工具一下子给你投票。

虽然一个用户有多个 openId，但这些 id 是和公共号一一对应的。你伪造的上哪里去对应？对不上就拿不到用户身份，就没法通过验证。

正在慢慢搞，这个行业大多需要定制化的，很不好搞啊。salesforce 这种很多地方是玩不转的。

@fengchang 我一个人开发也搞微服务。只需要写业务模块的代码就搞定整个项目，完全不需要关心那些和业务无关的功能，包括但不限于：用户、组织机构、权限、账务、支付、字典、报表模板、短信、邮件、消息通知、失败重试等等……

微服务属于那种一次投入终身受益的事。既然已经投入过了，我何苦不接受这个好处非得每个项目自己搞一套呢？用一套现成的他不香吗？

微服务有必要。对付这种需求变更频繁，业务组成复杂的情况，微服务就是最好的解决方案了。但搞微服务，你们要先搞定 devops，要对 ddd 有所理解，然后才能成。

至于高并发，你当他是买一送一的就行了。事实上微服务本身就是个分布式系统。搞定高并发，就是多部署几个实例的事。钱能直接解决的问题也就不是问题了。。。

rts 和 rpg 理论上可以做到全部运算都在服务端，客户端只能下指令。但 fps 只能客户端运算，所以作弊外挂屡禁不绝。

@594duck 现在也一样啊。微服务要做好是需要一些基石的，譬如 DevOps 、DDD 、Spring cloud，还有用户中心、账务中心、消息中心等业务无关的支撑服务。这些都是搞定了，就只剩下写写业务代码了。这样的微服务是很爽的，每个服务都很简单，开发快、上线快，并且易于扩展和维护。

微服务的核心优势就是把系统复杂度从开发转移给了运维，而运维靠 docker 、CI/CD 、k8s 这些技术解决了开发甩过来的复杂度，所以大家都很快乐。但如果你没有能力搞定运维，就会被干趴下，于是微服务对你就不是什么好事了。在服务拆分上面也一样，拆得不好，维护起来比单体更麻烦。

所以，是不是要上微服务，不是看规模大小，也不是看行业，而是看团队有没有这个能力。有能力就上，没能力就不要赶时髦硬上了。

@cokyhe 复制粘贴一次 2 分钟，照这样算的话，一天复制粘贴足足 240 次呢！我就不信没有重构代码的 1 小时时间。

再说，下个项目复制粘贴这次重构后的代码不香吗？

反正我写的那些 crud 项目，都是整个复制，稍稍改动下代码，重写 sql 就完成了。不说一天写完全部接口，有个 3 天的时间基本代码就写完了。反而在这之前，要花好几倍的时间做需求分析和流程梳理。

非结构化的地址自动处理成结构化地址是有一定的错误率的，楼主你把错误的抛出来人工处理或者干脆丢弃就行。

时间戳相同也有多个递增 id 的

这里建议楼主拿起法律武器维护自己的合法权益呢。当然，起诉的对象应该是恶意攻击楼主网站的人而不是腾讯云。

@sagaxu
@a719031256

现在都是这种注解写法吧……

@Results({@Result(property = "detail", column = "detail", javaType = Object.class, typeHandler = JsonTypeHandler.class)})
@Select("<script>select a.id, e.`name` as entity, a.type, a.`code`, a.`name`, a.balance, a.detail, a.is_invalid " +
"from iaf_account a join iab_entity e on e.id = a.entity_id where e.tenant_id = #{tenantId} " +
"<if test = 'key != null'>and (type = #{type} or `code` = #{key} or name like concat('%',#{key},'%')) </if>" +
"order by created_time desc</script>")
List<AccountDto> getAccounts(QueryDto dto);

压根不需要 xml

多台√
单台×

负载均衡不是一般都用 Nginx 的 upstream 吗？