1. 一款 web 应用，不能放在互联网，你们居然觉得理所应当？居然不觉得自相矛盾？
不是不能放互联网，而是既然你放在了互联网，你就要应该知道放互联网的风险。
2. gitlab 放在公开 web 上被黑了，你们一股脑都说是我的网络环境问题，gitlab 就毫无问题？ gitlab 本身漏洞百出也是理所应当？
所有东西都有漏洞，是你在使用的时候产生了混淆：Gitlab.com 一直没问题 != 我用私有部署的 Gitlab 上互联网也没问题
3. gitlab 官方也没说过必须放在内网才能用？你们在这自以为是什么东西？
我觉得大家已经给出足够多善意的建议了，只是在楼主在描述完贵司自认为的事实，认为己方全然无责后被喷，面子总会有点过不去…
4. 如果 gitlab 本身足够安全，放公网又如何？
还是那句话，所有东西都有漏洞。gitlab.com 的服务能面对公网，后面做了多少安全设施加固呢？
产品的安全是一时的，需要不断升级的安全策略和安全应对才是永恒的。

- 不允许申请公网 IP 的原因是什么？
申请公网 IP ，然后白名单只写公司公网出口 IP ，不也是一个不错的方法么。
如果开发需要在家访问的话，走 VPN 先回到公司，再走公司出口访问。

港区支付宝，其他区域 paypal

@YY 雀食，macOS 上叫 DevToysMac: https://github.com/ObuchiYuki/DevToysMac

@wherewhale 可以试试 Snipaste ，钉图片的功能一用就会爱上～

《成瘾剂量》也很不错

剪贴板工具：Maccy
菜单栏管理工具：Hidden Bar
截屏工具: Snipaste
鼠标滚轮平滑滚动: Mos
本地常用开发工具集(JSON 格式化\Base64 编解码等): DevToys

不懂前端，但后端日志无非是在理解业务大致流程的前提下，多向开发问问题，每次出现 trouble shooting 的时候，通过开发给出的信息尝试自己在日志里组织还原故障情况，一来二去就熟了。

技术分享对分享者来说，是一次自我的归纳和整理，以及练习表达的方式，我觉得挺好的。
对被分享者来说，从技术上是开拓视野，从方式上是学习他人的表达或者总结，看看有没有值得自己借鉴的地方。
单次的分享确实无法满足使用的技术深度，让楼主排斥的原因我觉得有可能不在技术分享本身，而是在分享之外的事情？

有可能是文件被删除，但句柄没释放。

帮别人做官网，建议从账号、服务器、域名、备案都用他们的账号，避免之后发生事情扯皮，保护双方。
老老实实用企业备案。

ctrl+f 搜 uid

换个角度想，如果是你，怎么把自己的课卖出去？
- 大厂项目经历背书；
- 社区贡献背书；
- 贩卖焦虑，再不学习就被优化；
- 除了提供课程，再额外贩售内推增值服务；

多放两把刀，减少吃坏肚子的风险，挺划算的。

因为 mv 只能做一件事情，所以要么增加别的命令辅助，要么换命令。比如 rsync:

mkdir dir1 dir2
touch root_file dir1/1_file dir2/2_file
rsync -av -R --remove-source-files * ./newDir

不过 rsync 也有个小毛病，--remove-source-files 不会删除原来的目录 dir1 dir2 （哪怕是已空）。

鉴于楼主已经发过一个帖子，建议直接买，不用再问意见了。

喜欢楼主贴的顾城的诗，能和意中人克服困难走到一起是一件多么幸运的事情。

执行 rm -rf 没有问题，但 rm -rf 后面千万不要加 ./* ， 因为你可能会忘记那个点...
我个人的做法是，使用“足够多的限定路径条件”。
比如要删除当前目录下所有内容，不能在当前目录操作，而是返回到上一层，这样限定路径就从 ./ 变成了 ./some_folder 。
或者是先 mv some_folder some_folder_to_delete ，这样执行 rm -rf some_folder_to_delete 的时候，因为有 to_delete 限制，也不怕输错目录名。
总而言之，就是尽可能的添加路径条件限定。