@yukiww233 有点奇怪，我刚在别处问过，有人说群晖的系统的数据只能用群晖读，换 windows 还是 linux 都是没办法读出来的。一下不知道该听谁的了

@yechengzhe 致态不做内存，它做 SSD 的

@stinkytofu 云服务器就是贵啊，不然前段时间怎么一堆文章说下云节约成本呢，云服务器根本没有变便宜，无非是你之前花钱养运维人员，现在把运维费直接给云服务器商而已。这么多年后云服务器商起来后态度也开始傲慢了，我基础设施，人人要有用，凭什么不多收点呢？于是很多商家又开始下云，觉得还是养点运维人员制衡一下云服务商比较好

楼主你在三年前买那台服务器的时候，绝对是没认真看它给你的打折优惠的，很多云服务器商在拉新的时候，直接打 0.1 折打断腿的价格，就是为了把你拉进来。然后等你用完时间续费的时候，价格就变原价了。
解决方法呢，也有，原来那台不续费了，到期关闭，然后云服务商的推销多半就会电话找你，你问它有没有优惠，它大概念又会给你一个优惠价格。

所以，要点就是，千万不要被云服务商绑定，搞成不得不续费的关系，那就会变成带宰的肥羊。我现在用云就是这样，到期旧服务器关闭，如果有优惠就开新的，没有优惠就换一家，让这一家空窗，空窗一段时间，你又会变成新用户

谢谢各位，确认是光猫上的防火墙无法关闭，导致无法通过 ipv6 从外部进来。已经准备打客服改桥接模式了

现在国内为了避免引来美国的注意，凡是在搞算力这块的公司都不对外宣称自己拥有的算力，总体上算力处于供不应求的状态，所以目前你想租成规模的算力恐怕比较难

我非常的奇怪，你们这些在大厂的程序员，如此的没有法律和安全常识吗？没有就算了，对自己可能入狱的行为也没有一点敏感吗？

@yimiaoxiehou 我们提出建立上传附件和相关引用数据之间的关联这点后，技术部门的老大排版要求存储部门完成这个事情。存储部门就很反感，而如业务部门里的我要把这个事情接下来，需要顾忌业务部门的其它人愿不愿意，毕竟多一事不如少一事


@brader 有一种表单，其内容比较多，一边编辑，则能够一边保存。保存后不会关闭表单界面，以允许用户继续编辑。那么，在这种 UI 下，如果你一点保存，就把临时目录下的所有文件移动了正式目录，这显然会改变这些文件的预览地址，那么表单界面上预览这些文件的 url 就必须跟着变，不变的话预览图片之类的东西就会变红×。所以临时目录这功能只适合那种，点了保存，表单 UI 就消失跳转，要编辑这条记录需要重新打开，这种场景。

谢谢大家的解答，我综合了一下，看来还是引用计数比较合理一些，剩下的就是说服存储部门的人了。当然，也可能还是搞不定，就放弃了，毕竟就像楼上有人提到的，这年头存储确实不太值钱。

@cp19890714 你这个方案似乎比直接关联业务 id 和文件 id 的方案要好一点，至少我可以不管存储部门，直接在我业务部门这边自己建表，我会考虑一下这个方案


@nothingistrue 也是我自己蛋疼，其实这个看起来的小问题，真想做好要考虑很多方面，团队之前也是倾向于不管的，我是自己闲得无聊，希望找到最优解


@brader 临时目录方案有缺陷的，我顶楼说了的，遇到那种保存数据时候不跳转页面，仍然停留在当前编辑页面的表单，这种方案要吃瘪，因为移动文件会改变文件的访问 url ，间接导致页面引用地址需要变更。


@akjarjash 就是因为搞久了才会胡思乱想，想找到一个便宜，简单，又优雅的方案解决这个看起来很小的问题


@janus77 对，附件修改引用也是个比较头疼的问题

@samnya 这个上传文件记录 file 表，，然后记录其引用的业务数据 id 的方式，我们曾经尝试过，它的弱点就是把上传文件这个行为和业务数据强相关了，你每次上传文件，保存数据后，必须更新文件记录表，把相关的业务数据 id 传进来。本来存储是个很独立的事情，结果现在存储部门还得管业务引用的事情，搞了几次后存储部门非常反感这个方案，在也是为啥这个方案最终没用长的原因


@JamesR
你的方案里存在一个问题，就是，我怎么知道哪些附件没用呢？之所以有 [挪动文件] 这个解决方案，其实就是在挪动的时候，把这一波和当前业务数据有关的附件 id ，全部移动到特定目录去，那么剩下的自然就不相关了，自然可以随便删，但是问题是这个方案它不够好，问题我顶楼说了。


@yolee599 现在就是没有比较好的办法，确定哪些文件没有用，特别是文件比较多的时候


@yimiaoxiehou 引用计数方案其实就是 samnya 的那个方案，这个方案需要建立文件 id 和对其引用的业务数据 id 之间的映射关系，存储部门非常反感这个方案

@FreeTPGods 你才是站着说话不腰疼好吧。
公司规定就这，不服你唯一的选择就是 run ，你想技术突破？送你吃牢饭没商量，1 楼才是最正确的建议。

12 万分的不推荐 wsl2 ，那玩意底层就是个虚拟机，你还不如直接上虚拟机呢。想玩 linux 就直接上虚拟机就好了

你们要自己从头实现一个 HDFS ？还要用 C 来实现？我能否问贵方打算投入多少人进去？ HDFS 当年也是投入了不少人力的，我记得围绕其还有公司的起起落落

@zackkson1991 请教 TailwindCSS 这个东西和 bootstrap 的区别在哪里？

@pengtdyd CSS 非常非常难。

知乎有个问答里，对 CSS 的难度做过分析，首要问题就是 CSS 是不正交的，你改变了 A ，会奇怪的影响到 B 。即它存在大量的隐式条件和输入，导致你在推导结果的过程中，在大脑里必须得预加载条件输入方案，而且这个方案数量并不低。大约有十几种组合，这些组合是你要背的。绝大部分传统程序员，是习惯以逐行代码推导来进行思维过程的，天生不适应这种非正交系统。

其次就是 CSS 的调试工具至今没有得到足够的改善，要知道 CSS 调试的目的往往是为了解决“这个该死的盒子为啥在这里？”或者“那个该死的样式为啥就不起效”之类的问题，然而目前的浏览器调试工具，只能提供当前盒子受影响的条件参数，但是很多时候，影响这个盒子样式的原因，在十万八千里之外的另外一个盒子身上（这又是该死的非正交问题）。这和编程调试器在大多数能很方便把问题定位在一个非常小区域的上下文之上，很方便的找到问题，完全不是一个级别的。恕我直言，CSS 调试工具目前的能力非常落后。这种落后在于 CSS 系统里任何一个盒子的样式是受到诸多不在这个盒子上的，其它盒子的参数影响，最后被浏览器推导出来的，然而浏览器的 CSS 调试工具却不具备逆向推导的能力。这导致很多时候非常难以发现问题在哪里，于是我们会看到很多自称学会 CSS 的人，他们也改不了别人的 CSS 源码，他们解决问题最常见的一招就是：按自己的习惯完全重新写一遍。

所以从上面你也看到，很多自认为学会了 CSS 的人，其实并没有学会 CSS ，它们只是熟练的 CSS 搬砖工而已，判断这个人是否真的掌握了 CSS ，要看它能不能对一个已经存在的，且比较复杂页面的 CSS 代码进行推导和修改，即能能准确的分析中的某个盒子的样式到底是如何被影响的，然而通过那十几种组合，快速的研究出改哪里会生效。而现实中却往往是：md 搞不懂为啥，重写一遍！

所以 CSS 真的是很难，不过这个难是相对程序员说的，因为 CSS 是另外一种思维，它最初被设计出来是为了排版系统准备的，也许在排版领域，这东西设计的很好。但是换到程序员，这种从一开始就是培养逐行推理思路的领域，天生就不匹配。所以，学不会就学不会吧，像我至今就不敢说自己学会了 CSS ，虽然我有时候甚至可以用 CSS 问住搞前端的同学，但是我自己是很清楚的，我不会 CSS

@pengtdyd 注册美国公司？那岂不是还要跑海外去才能做到，能跑海外的话，就不会有收款问题了，大部分国内作者有收款问题就是因为不方便出去