纯水机长期来看就 RO 膜滤芯的耗材稍微贵一点，买通用规格的划算一些

第二种，或者 sizeOfName

0 是作为默认值的，可以减少序列化以后的体积大小，当你反序列化以后，创建出来的数据结构里面的 age 字段在没有设置的时候，也是 0 值，所以从结果上来看是没有什么影响的。

思路放开一点，将查询和命令分离开来，这样会清晰很多，表结构也不用为了查询而影响到 OLTP 的处理。基本的思路就是，你不知道将来会有什么查询的需求，在设计表结构的时候，应当根据实际的业务操作来进行设计，这样你在建模 Entity 的时候，就是跟数据库的表结构相对一致的。

我也建议用 JPA 来进行 OLTP 业务类型的建模和操作，用 MyBatis 来进行自定义查询相关的处理，是的，你不用只使用一种技术或者框架，虽然好像你会写更多的代码，但实际上这样做了以后你会发现思想负担会减少很多，也更有信心进行修改和重构。

简单一点的直接用 markdown 文档了。

前后端统一就行（意味着有一个文档来进行维护，类似字典），至于值是什么在编写代码的时候无关紧要，值只有在传输或者存储的时候才会被用到。不同语言的对于枚举这个东西定义还不一样，不过逻辑上来讲枚举通常意义下就是一个有限的集合，这个集合里面定义的每一个枚举单位都是独一无二的，这样就可以借助语言的特性来进行一些约束性的操作。

我之前跟你的情况是一样的，状态为 clientHold ，阿里云的，打电话联系客服没用，包括联系相关部门，也是告知不知道这回事，遇到这种情况没有什么办法，只能认账了。

要我说最好的办法就是直接做一个练手的项目实践一下，在实践的过程中不断的解决问题和优化问题的解法，这样学习效率是最高的，只有亲自动手做过一遍之后，你才能知道个人的学习成果如何，知道该去学习什么东西才能得到更进一步的提升。

ID：2272338 ，支持一下

https://hexed.it

这个还不错，直接浏览器打开就行了

我理解的你这个 APP 的激活是不是类似于签发密钥然后激活的单机授权模式，也就是用户在没有联网的情况下也能正常付费激活，比如私钥签名，然后 APP 校验，没问题的话就读取里面的授权信息，激活就算成功了？

如果破解者能够把你的授权部分修改掉，伪造出授权成功的信息通过校验，那么你的 APP 就会认为这确实是已经付费的正常用户。除此之外你在没有授权时做的任何校验都失去了存在的意义。

因此在你做各种校验之前，最好先考虑一下哪一部分才是最关键的。

加固就行了，除非是特别特别需要防止别人破解的 APP ，这个时候才应该考虑在源代码级别上面进行特殊的逻辑处理，另外也可以花钱买专业的加固工具，权衡利弊选择适合的就可以啦。操作系统都能被破解，iOS 都能被越狱，更别说 APP 了。抱着学习的态度去尝试了解这一行也是有价值收获的。

不太懂这一块，国外的劳务合同应该走国外的劳动政策吧，对应过来在国内是什么存在呢？感觉有点像是外包私活性质了，有点好奇这种私对私转账会不会引起注意？个税申报也是在汇算清缴的时候自己填上去？

这个不是单元测试吧，这个算是集成测试了，需要在独立的测试进程中对其进行测试，就好像是应用程序的真实使用者一样。

对于单元测试，如果测试的目标依赖了一个外部的组件，常用的做法是对这种外部组件进行 Mock ，比如测试目标需要一个发送消息的服务（ MessagePublisher ），可以 Mock 一个消息发送服务（ InMemoryMessagePublisher ），然后对测试目标进行测试，并观察 InMemoryMessagePublisher 中的结果是否符合预期，当然这只是一个很简单的例子，因为单元测试足够小，所以可以反复快速的完成测试内容。

测试是一个很复杂的概念，每个人或者组织都有不同的偏好，在我看来归根结底无非就是两个问题，那就是搞清楚我们到底在测试什么？我们期望测试将来可以起到什么帮助？

@bk201 我用的是添可的洗地机（芙万 2.0 ），型号差异感觉并不是很大，主要是清理方便。

Ioc 的主要作用就是读取组件声明（ XML/注解 /代码注册），也就是构造 IoC ，然后实例化和管理这些组件的生命周期。
根据构造组件所需要的定义（面向对象语言中通常是 class 的构造函数），就可以得到创建这些组件所需要的先后顺序，从而不必手动去硬编码这个过程。
另外 IoC 本身的生命周期（创建 /销毁）形成了一个 scope 作用域，从而可以管理存在于容器内的各种实例。
所以一般 IoC 有两个阶段，一个阶段是读取声明（注册组件，构造 IoC ），另一个阶段是构造和管理组件。

对于非面向对象的语言，我能想到的就是在读取组件定义这一块（即对应面向对象中 class 的构造函数），转变为了一个 Key 和包含回调函数的 struct 。
这个 key 可能就是一个简单的字符串，类似 map 或者 dict 中的 Key 。
这个 struct 由 IoC 定义，里面包含了初始化定义（依赖描述），生命周期回调函数（函数签名由 IoC 定义），以及一个指向实际值的 interface{}指针。
上面说到 IoC 本身也是有生命周期的，它提供了一种作用域的语义，因此可以很方便的管理一系列组件的实例。

另外说一下 SpringBoot 的各种 starter 也只是提供了一个默认的组装布局，或者称之为开箱即用的默认配置，只不过可以根据配置文件来自动进行组装逻辑，这就需要提供一种通用的描述规范。

洗地机很好用，我是一点容不得地上有什么污渍的，比如有一根毛发也要用纸把他给清理掉，可能是有点强迫症，甚至在吃饭的时候会时不时扭头绕着身子观察地面上有没有什么东西，这个毛病怎么也改不了。

没明白你说的对用户不友好是啥意思，往一个已经删除的关联数据增加新的数据，按理说应该失败并告知原因，例如不存在 menu ，除此之外还能怎么做呢？可以吞掉这个错误，就当请求没发生，或者正常插入脏数据？

数据已被删除是一个事实，优化的方案也可以当有用户编辑 menu 的时候不允许删除，这取决于想要的逻辑是什么。

回到正题，解决这个并发问题最简单的方法就是使用乐观锁，或者直接使用独占锁（ SELECT ... FOR UPDATE ）。如果是独占锁，当你在进行操作的时候（新增 content ），别人是没办法查询或者修改这个 menu 的。当完成操作，另一个试图删除 menu 的时候，走正常的删除逻辑。