课代表总结：一将无能累死千军。

@buxudashi
@leimao

不吃发育得没啥问题 != 吃了也不能发育得更好。

至少从保健的角度讲，对视力、身高都是有好处的，视力好，耳聪目明就占了一项、对于个体的感知系统有好处。视力好不等于智力好，但是如果本身智力就强，至少视力好对于信息输入源是个增强进而对于智力也是有些好处的。

至于本来智商就不在线的，那视力再好也只是体育相关的增强为主了。

百度百科吹的很多就不贴了，维基百科相对中肯：

母乳中 DHA 佔所有脂肪酸的比例從 0.07%到超過 1.0%不等，平均值約為 0.34%。若婦女食用較多的魚類，其母乳中 DHA 的含量也會較高。魚類及貝類 DHA 含量高，但其中也會受到微量的汞污染。美國的食品及藥物管理局已提出對於孕婦、計劃懷孕婦女、哺乳婦女及小孩所食用魚類及貝類中汞含量的關切[7]。

最近開始建議孕婦補充 DHA ，指出有關 DHA 對於注意力及視力改善的相關研究，並且指出大部份中国的孕婦飲食攝取的 DHA 都未達到其「建議量」[8]。國際脂肪酸及脂質研究學會（ International Society for the Study of Fatty Acids and Lipids ）的一個工作小組認為孕婦及哺乳婦女 DHA 的建議攝取量是每天 300 mg ，而此階段的婦女每天 DHA 的消耗量介於 45 mg 到 115 mg 之間。March of Dimes 組織（英语：March of Dimes ）的建議量則是每天 200 mg[9]，其他來源資料也有提出不同的建議量[10]。
DHA 营养干预对优生优育，以及婴幼儿健康成长很重要，母亲孕期即开始合理的进行 DHA 营养干预，更利于优生。[11] 尽管有上述补充 DHA 的建议，2017 年发表的一项妊娠期妇女服用 800 mg/day DHA 补充剂和安慰剂的随机实验结果表明，在孩子出生后的 7 年的跟踪过程中，孕期服用 DHA 补充剂对子女的认知能力并无影响。[12]

相比余大嘴重新定义了什么叫“彻底没电“，这个至少丝滑一些

@iseki
默认值不一定是 0 。
结合产品需求的默认值设计，我#33 已经明确讲过了，#42 有更多补充。

@RedBeanIce #37
"请问一下，一个非必填字段。如何判断用户输入 0 ，还是 default 0 ，，"
—— 你既然根据产品规则设置了默认是 0 ，也就是可以给用户端 0 用来展示，那不管是不是用户输入的 0 ，都是正确的作为前端展示的值。
搞清楚一点，提高产品思维，这个前提下，实现业务逻辑的重点是为了产品合理性，而不是为了去满足你区分到底是不是用户输入的强迫症需求

#39 "产品规则可控，感觉好麻烦。。。。"
—— 我们程序员骂产品"狗"的时候，很多是因为产品不懂技术瓶颈压力、随便什么需求都敢提
—— 而产品骂程序员的时候也很多是因为程序员只考虑技术、不考虑产品

前阵子雷军不好举例子他亲自下场去当销售才体会到技术人员太执着于技术了做不好产品的嘛

嫌麻烦，其实就是咱没经历过好厂好项目好规范的训练，作坊式的生产、不规范习惯了导致了懒惰，然后反倒去以为别人这么做是多余、说人家麻烦。。

规范、严谨的工程，比如知名开源，或者硅谷那些知名厂的多数项目，规范化得多，提交、合并流程各种繁琐。说起来麻烦，但确实这很规范，大家都规范，也是对自己能力的提升

@RedBeanIce #29

对于用户是否应该必填字段，产品规则是可控的，即使不需要用户输入；
默认值也是产品规则可控的，比如字符串类型，一般默认就""，用户如果可以不输入，""也没问题。数值类型 0 值同样道理。

但是数据库 null 对于不同语言处理起来可能会遇到不同的麻烦。而对于默认值。

不喜欢 not null default 的各位，建议还是反思下自己吧

支持 not null default +1
支持 bigint 时间戳 +1

@rrfeng “真搞不懂哪里来的优越感和这么喜欢批判别人”

补充一点，不是批判 OP 你这个人，是说这个语法糖这个实现

@rrfeng
这不是优越感，只是我这个人说话比较实在并且直接，你听了可能会不舒服而已。
至于为什么这样不懂得客气，是因为有过太多因为客气委婉、别人反倒以为自己没问题，所以我不想再客气了，有问题就尖酸刻薄地指出，至少对于技术本身，是中肯切实的

批判跟优越感也没有直接关系。
批判纯粹是因为你做的这个语法糖是一种倒退，如果没有其他人参与讨论我就不会来留言了，但是看到其他人也参与了讨论并且没有意识到这种语法糖是倒退，这就可能导致有更多人被误导。

同样有一些其他人参考其他语言做一些对于 go 而言是倒退的东西，如果力所能及，我也都会献上一些建议不要这样做的刻薄说辞

但我不只是空口乱喷，讲了一些点的，OP 要是能静下心来回到技术本身，对自己是有好处的

OP 不要纠结我的说话方式，你就当我是个没礼貌的小学生无视我的不客气好了。对其他人也一样，每个人隔三差五总会遇到让自己不舒服的人，我们没法改变环境，但是能适应环境，只要不是切实伤害，自己内心强大就无所谓别人客气不客气了

已经好些人说我刻薄之类的了，我自己也知道并且欣赏自己的刻薄。刻薄并不是什么坏事情，这世界，总是需要有一些刻薄的人的

良药苦口，忠言逆耳，认真思考技术就行了，共勉

这玩意相比与 goroutine 是倒退，跟你帖子主题说自己搞的这个东西是否牛逼没关系。

@rrfeng 我只是劝你别研究这种吃力不讨好的东西了，如果你目前阶段的修为 get 不到，就忽略我说的吧。期待未来的某天或许你会恍然大悟

遇到这种现象一定要相信是自己的问题而不是 go 真的牛逼到可以吊打 c/cpp/rust

@pastor #14 "二院" -> "而言"

go 的哲学，就是让大家从语法语义中解放出来，这种 async/await 的设计，其实本质上都不算是 lib 封装了，而是更偏于语法语义的语法糖的设计。不管花多少时间玩这种东西，到头来总有一天会想明白，发现竹篮打水。越早回头是岸越划算

还有就是，如果你的业务依赖这种同时多个异步的，最麻烦的地方并不是封装这种 async/await 的绕脑的写法，而是实际场景中每个异步请求可能失败后怎么处理。

这对于不同的业务场景没有固定答案，比如爬虫或者什么，失败了也影响不大；但是对于具有事务性要求的业务，这种同时依赖多个异步远不如串行顺序处理好。对性能有很高要求的八成也应该是依赖自家的基础设施，这种如果还能设计成同时多个异步，那说明你们整体架构已经出问题了、比如微服务拆分得非常不合理，这种要治病得从架构顶层往下梳理而不是脚疼医脚。

@rrfeng
第一，如果没有先后顺序，那有序调用也是满足要求的，for 循环挨个调用就可以
第二，如果有性能要求，同时去请求 10 个才能满足性能，那 wg.Add(10) go func() { defer wg.Done() ... } 也比 async/await 可读性舒服得多，如果这种异步量大这里可以用协程池而不是直接 go

对于异步理解比较到位的人二院，async/await 并不比 Promise 之类算是改进，相比于 go 可读性就更不直观了

协程本身就比 async/await 易用、可读性强，OP 搞这种玩意可以加深下自己对协程之类的玩法，但如果真应用到业务里，那就是坑队友了。

我昨天看了这个帖子标题手滑点进来都没看内容就直接就给关闭了，今天发现竟然有人回复，就又点进来

本末倒置的玩法，不值得浪费时间，奉劝各位早点散了吧

@hxndg 我对 tls 的描述不准确，感谢指出！

"一般如果没有明确的需求不建议自己定安全需求。"
这个除了少数安全要求很高的项目，绝大多数场景，都是程序员自己负责了基本的安全策略，不可能每个公司都专门的安全部门去指导业务开发来实施这个，比如我上面举例子的几点，虽然没人明确列出行业规范，但类似的实现也差不多是基操了。所以说没有明确的需求是正确的，但是业务程序员自己不去管安全需求也是不太正确的

@Al0rid4l #91
@shyangs #95

你俩这两楼误解我意思了。我上面举数据库的例子是为了说明任何措施不能保证百分百，还包括社工之类的。
因为我看 @Al0rid4l 的观点给我的感觉就是”既然前端不能百分百还做它何用“，所以举例子说明：
不只是前端，后端、数据库同样不能保证百分百，但是后端、数据库仍然要做；
进一步来反驳 @Al0rid4l “做它何用” 的观点，不是用来论证因为数据库需要密文所以应该由前端开始密文。

但是话说回来，至少我遇到过的合理的项目，都是从前端开始密文的，前面也举过前端页面别人 F12 的例子了，麻烦 @Al0rid4l 看明白了再来评判