@wangyuyang3 关于协议层和价值激励是个很宽泛的话题：各个公链的共识激励、NFT 的创作者分润、DeFi 的流动性挖矿等都属于这个范畴，应该没有文章直接围绕协议层来讲毕竟是个过于泛泛的命题。

至于关于什么是 Web3 主流，我自己的定义是那些主流公链和 DeFi 、蓝筹 NFT 、以及围绕这些项目的生态（交易所、投资方、分析师等）这些人的观点虽然不一定对，但确实是行业里影响力最大的一批人。

关于数据所有权，目前生态里真正意义跑通并产生广泛影响的，我觉得只有交易（以虚拟货币为代表）和金融（以 DeFi 为代表）这两个领域。它们的共性是数据天然具备强价值属性，所以数据所有权以财产所有权的形式直接实现了。至于你比较关心的内容 /社交领域的数据所有权，确实有不少讨论，但之所以有很多讨论也就说明大家并没有看到一个比较明确的实现路径。反而像比特币这种，几乎没有人在当下讨论比特币的数据所有权问题，因为这无需讨论，甚至我们已经开始遗忘比特币本质也是一个数据罢了。然而比特币可能才是 2022 的当下应用最为广泛的数据所有权。

@wangyuyang3 你的逻辑是对的，但是预设太多了呀，基本上你把数据所有权问题限制在创作版权和内容平台这两个领域下。且不说这两个领域只是数据所有权的很小一部分体现了，当下 web3 主流也并没在谈论版权和平台，而更多地在讲 cc0 （无版权）和协议层（弱化平台属性）。web3 虽然想解决平台垄断，但核心内容并不是直接建立一个无垄断的平台，而是把目标放在协议层和价值激励上。所以你对内容排序、用户曝光等围绕内容平台的讨论虽然很合乎逻辑，但是读起来总给我重拳打到棉花上的感觉，毕竟 web3 的并不是平台逻辑而是协议逻辑呀！

所以我觉得你的文章虽然逻辑推演是严密的，但是立论上就是以偏概全的了。如果 “web3” 替换为 “版权和平台逻辑下的 web3”，“数据所有权” 替换为“版权和平台逻辑下的数据所有权”，可能更严谨一些

@wangyuyang3 略读了下你的文章，感觉虽然很合乎逻辑但忽略了一些重要前提，尤其是关于数据所有权是否是伪需求这一部分。这里的重要前提是：数据所有权不是一个假设上的需求，而是已然发生的事实。当数据具备价值属性，成为个人财产时，数据所有权就以财产所有权的形式存在了。比特币就是数据作为个人财产最有力的事实论据。当然你可以说比特币只是这个荒谬时代的产物，终究会走向覆灭 blabla 。不过这个话题就没什么讨论的意义了

这几点就是 web3 宣称要解决的问题吧，也确实有一些 web3 项目做到了这几点，虽然是以牺牲性能和用户体验为代价

邀请制是一种用户运营和增长手段。运营手段是否有效，得结合你的产品功能和定位来看。例如你的社区产品面向的用户画像是什么，为他们提供什么内容和价值，然后才能分析邀请制是不是有效的增长手段。脱离产品形态谈运营手段，这不扯淡吗

大多数面试官问算法主要还是为了考察编码习惯和代码风格，要么就是候选者是应届生没啥项目经验，只能多考考算法

仅就深度分页，scroll 的主要提升来自基于 scroll_id + server 端 context 实现的类似游标查询。
以分页大小 100 ，查询第 100 页为例：普通分页查询（ from/size ）需要对 0~100100 的数据进行查询和排序，而游标查询根据 scroll_id 可以不再需要查询和处理 0~10000 的数据，所以不存在深度分页下的性能问题。scroll 还是需要 query/fetch 等阶段，只是处理的数据量都减少了。

也看了关于 Duolingo 的介绍，可以再讲讲对比 Duolingo 的话 Busuu 有什么优劣吗？对于初学者以及有一定基础的学习者，哪个 app 更好呢？
另外给个小建议，因为内容比较长，建议在正文开始可以给一些 takeaways ，阅读体验会好一些~

@murmur 问题不是组件库好不好看，而是用 ant 这类组件库基本就屏蔽了 css 达不到学习目的。用 Tailwind 也可以直接抄别人写好的 UI ，不需要自己组合，而且根据 className 直接就可以知道对应的 native css 是怎样的，后面转 css 就容易多了。反正我自己用 ant 这类组件库是没搞懂 css ，而用 Tailwind 写了两三个小项目基本就知道 css 该咋写了。Tailwind 语义性确实是个问题，但更多影响的大项目的可维护性，对于新手学习来说没有太大影响

我自己是 React ，因为油管上 React 的优质教程比 Vue 多一些，但其实入门的话资源都不少，区别不大。CSS 的话蛮推荐简单了解下之后直接上 Tailwind CSS 的，既可以避开一些新手不友好的 CSS 技术细节，但又不至于像 ant 这类组件库一样完全屏蔽了 CSS ，达不到学习目的

error 的处理逻辑最好是可以作为参数传入的而不是默认 panic ？类似传入一个 func(err) ，这样更 general 一点，也比较接近 try-catch 的范式

which means 就算用 Slack 但公司文化还是钉钉文化，那办公的体验还是跟用钉钉差不多

选择 Slack 和选择钉钉的公司基本上都有管理方式和文化上的不同，影响协作办公的更多是公司管理和文化而非 IM 工具。在用钉钉的公司，我会觉得自己需要及时回消息；在用 Slack 的公司，大家都默认晚点回复也没关系

并发瓶颈是什么呢？ 500 qps 估计应该不是 service 层而是数据库的问题。
如果是数据库问题那用 serverless 的意义不大。
就算是 service 层问题，更简单有效的方式应该是搞个 cronjob 在抽奖之前执行扩容任务，因为抽奖时间应该是可以提前知道的？

很棒的文章！最近刚好也在搞个人项目的 infra ，很受用。另外想问下楼主有尝试过用 AWS lambda 之类的来托管后端吗？目前打算 all in lambda

CLI init 也只是创建了个 yaml ，从官网的 example copy 一个下来就行

只考虑「数据库设计」意义不大，得放在「系统设计」这个大问题下面来思考。没有什么 app 是只有数据库就能 run 的，同理数据库设计和 API 设计、架构设计、业务逻辑设计等问题都是无法分开讨论的。所以大厂面试考的都是系统设计题，而不是数据库设计题

多看看其他优秀同事的代码，这样学习效率会比看书来得快得多。mentor 说你代码不行不就意味着有其他同事写得比你好嘛，看他们的代码，先模仿着写，然后不理解的地方当面咨询。工程问题的很多 insight 并不是在科班课程能教会你的，科班更多的是解决学术问题~