微软自己的客服说可以。

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 谁会代替谁还不一定呢。

还是招人把这个项目重写了吧。
这个项目用了 MFC 很有可能还用了 ATL COM 等，即使是现在熟悉 C++的工程师也没人想再碰这些了

成本从低到高分别是：电力猫，隐形光纤，mesh，重新装修，再买个房

对象存储是不支持随机写入的，COSFS 文档里明确写了「随机或者追加写文件会导致整个文件的下载以及重新上传」

至少换成支持随机写入的文件存储或块存储吧

如果不需要反向查询（用手机号找谁的通讯录里有这个号），那么就每个手机号用 5 个字节表示，每个用户存 200 条手机号就是 1KB，全部 10 万用户的通讯录总共 100MB 空间，随便找个方案就能存下。

还有个可能是与境外的 UDP 流量过大，触发了对全部境外 UDP 流量的阻断。