从商业角度上分析，这基本是不可能的。
其实我希望两家网盘都持续存在下去，这样才会有竞争。
之前我迫切的希望换掉百度网盘，就是因为它的下载速度 10kb 都不到，现在阿里网盘出来后，百度网盘提速了，下载有 1MB 速度，就觉得换不换都无所谓了。

不过用户希望免费是没错，但商业不是在做慈善，要存在下去，收费是必然的，只是我觉得应该有更多维度，更合理的收费方式，因为一些人，真的只是偶尔用，这种你让他每月掏 25 元，我觉得这种就不太合理。
其实合理的收费人家是不会抵制的，酷狗音乐和视频网站，不也开始收费了吗，用户也慢慢接受了，但我觉得这些会员的价格是比较合理的。

@iXInbo 总结起来就是，与领导工作关系平和、顺畅，没有任何私交。项目不忙，是核心成员。我现在去面过几家，也是和你想的一样，我说的上岗时间是 2 到 3 周。就是不知道到时候能不能走。

来啦来啦，又要推荐我的 https://github.com/wenshunbiao/docker 了

@lifesimple 这种事怎么可能说出来，哈哈哈，你不想裸辞，没拿到 offer 之前，难道会告诉别人你要走吗

@ymcz852 所以这点很难搞，想问下你们有没有经验，因为谁都不想裸辞啊。但是去面试，说 30 天上岗，很难面

一、qq 截图，保存的时候是可以选择 jpg 的。
二、可以考虑使用 FSCapture 。这个软件，设置里是可以设置默认图片格式的

又到晒博客时间了吗 https://brad.9iqu.cn/

一、token 有一个刷新有效期的，这个有效期过了，是无法进行刷新的。
二、用户反馈账号被盗后，应该要禁止用户登录。
三、将当前有效期内的 token 全部列入黑名单。

呀，楼主也做过区块链的啊，我也是咦，我接过 Bitcoin 、OmniToken 、BitcoinCash 、UnitedBitcoin 、Litecoin 、Decred 、Ethereum 、EthereumClassic 、Grin 、Beam 等各种币种，能谈谈你的感受吗？
我自己做这个感觉好累，不太想做这行了，主要是因为，经常叫你接新币种，大部分是国外的，英文文档，本人英文又不太好，有一些币种，文档又不全、难找。
然后我们做这个，安全性要求又高，压力好大，里面动不动几千万，我真怕哪天钱不见了找我赔。
还有就是做这个，一些有些客户的业务总是带一点灰色的，大钱又不是我赚，我真怕哪天我钱没赚到，人还进去了。

用 Tampermonkey 扩展吧，https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo
这个能编写自己的 js 脚本，自己写个脚本反覆盖回去就好了。

timestamp 接受一个时间字符串。
建议用 int 吧，我做了这么多项目，都是一直用的 int

这确实是个问题，需要今晚好好研究下

我劝你不要多管闲事 0 0 ！你举报了我们看什么

@daijinming 一两个域名，直接在 /etc/hosts 加一下挺方便的

参考 k8s，k8s 的内部集群通讯的域名解析，就是通过内置一个 dns 服务器实现的。

@abcbuzhiming 会删除 A 文件的，这是完全没有问题的，因为你自己说了，你解决 hotfix 的办法就是删除了 A 文件。那么 A 文件的存在就是一个 BUG，所以你希望的 dev 分支也解决掉这个 BUG，那你就是要删除了 A 文件，如果说，不删除 A 文件也能解决 BUG，那么就说明你前面为了解决 BUG 而删除 A 文件的行为不是最优解。

这里我再补充一点，只有非常紧急的 BUG，才走上面的一个流程。
正常修复普通不紧急的 BUG，个人建议最好还是走平时的正常流程（开分支->修复->测试->上线）。
git 是鼓励你频繁创建分支以及删除分支的，因为你线上使用的总是 master 分支，所以你的其他分支是无需合并本次 bug 修复的，因为该分支在开发完，就会被你删除，而后的新东西，你总是从 master 切个新分支出来。

或者你还有一个持久存在的 dev 分支，那么你的 dev 分支，应该总是不定时的从 master 分支获得修复反哺。

我们可以从优秀的项目身上借鉴经验，让我们来看一个案例，前段时间（ 4 月 15 日），以太坊柏林硬分叉，openethereum 节点进行 Berlin hotfix 的一个案例：

- https://github.com/openethereum/openethereum/pull/366

- https://github.com/openethereum/openethereum/commits/dev

我们观看上面两个链接的 git 工作流，可以看到他的 hotfix 流程大致是这样的：

- Merge branch 'berlin_hotfix' into release/v3.2.1
- Merge branch 'release/v3.2.x' into main
- Merge branch 'main' into dev

从这里相信你能看出，当出现一个紧急严重的 bug 的时候，你首先应该做的是第一时间、最短时间解决线上的漏洞，抛开一切繁琐的影响你解决问题的因素（不要再去想其他分支的事情了，你已经没有时间了）。

你首先应该从当前发布版本切出一个 hotfix 分支，修复后，第一时间将该修补提交合并到新的发布版本，这时候你已经完成了你最应该做的，最紧急的事情，接下来，你就可以按部就班的，逐步将该修复合并到其他分支。


当然，我们现实项目中，可能少了像开源项目有发布版本这个 tag，我们的线上可能就是 master 分支，但是原理是一样的。

@br00k 比如，我们正常希望前端给我们传一个这样的 URL 资源地址：/110/images/a.png ，结果他构造了这样一个地址：/110/images/a.png#disabledFeatures=[]&enabledFeatures=%20[]&indicatorsFile=data:application/javascript,alert(1)

我们应该如何去防范他？