恰恰相反，有前端基础（ React/Vue ）比较好上手，有原生基础的会走很大的弯路

现在国内电商的趋势是直播带货冲动消费，做比价功能会降低销量所以不会有人做。

二十年前的互联网就是这样的，再也回不去了。

再次推销一下 sqlingo： https://github.com/lqs/sqlingo
https://i.v2ex.co/5keewT0Sl.gif

微软自己的客服说可以。

https://answers.microsoft.com/zh-hans/msoffice/forum/all/%E4%B8%AA%E4%BA%BA%E8%B4%AD%E4%B9%B0%E7%9A%84offic/78051eeb-ab13-47b3-8a7d-c3e28ae1522b?auth=1

可以参考「净室设计」 https://zh.wikipedia.org/zh-hans/%E5%87%80%E5%AE%A4%E8%AE%BE%E8%AE%A1

「先让某人检查系统如何重新实现，并撰写一份规范。然后律师审查这份规范，确保其不包含受到版权保护的资料。最后由与原检查员无关的团队实现该规范。」

更应该要干的事情是直接把 POJO 类的成员变量直接声明成 public 的，不要再受到古代教科书上说的「用 getter/setter 会更面向对象」这种过时思想的影响。

这么接

https://i.v2ex.co/ZTntDIeS.jpeg

@Mavious 前三个小时看似无聊的铺垫都是为了最后的结局可以感动到哭

几十年前就是这么干的：Windows 95 和 Office 95 同一天开始发售。

@gzlock 参考 SMTP 协议，接收者信息是在 RCPT TO 命令里指定的，可以不放在邮件头。

电子邮件的原理就是在模仿纸质信件，收件人和发件人都是可以随便填的，就像可以在纸质信封上随便写成谁然后放在你家信箱里。

@nullboy 你应该弃用这个品牌的硬盘，而不是弃用 nextcloud

无论是用 select/epool 还是普通的 read，底层都会用到中断，并设置一些状态。

然后 select 仍然是轮询上面设置的状态。epoll 是在中断里加了回调。

mitmproxy，快捷键像 vim，还可以接 Python 脚本

原则上 Service 层应该单独有一套业务对象，这样就可以把 UserService 里的接口设计成 List<UserBo> findUsers(UserSearchBo)，然后在 UserController 里对输入输出都做适配。

IPv4 和 IPv6 谁会代替谁还不一定呢。