就是直接新建一个普通的仓库啊，然后上传都用的这个仓库，你审批完成以后就复制到正式的仓库里面，其他项目引用下载的时候用的是正式的仓库。这样上传和下载就是分离的，使用的是不同的仓库地址。

不过我倒是很好奇你怎么审批？反编译看代码？

直接上传到一个待审的仓库，审核以后移动到正式的仓库。

confluence?

@alpha4zeta 就是 WDS ，一般无线路由器都有这个功能，相当于起了一个中继的作用，可以放大信号，让多台设备链接。

我家在街上，用的无线路由器桥接对面邻居家的 WIFI 信号，如果是小院子自建房那种，距离远的只能用光纤去借一下。

只需要一个像 Linus Torvalds 这种强有力的领导者即可

就跟喝醉了一样，睁开眼天旋地转，闭上眼螺旋式的陷入深渊。关键是脑子停不下来，一直纠结某一个画面片段，或许有这么一种可能，大脑真的就需要把注意力集中到某一个画面片段上，这个片段本身没有意义，只是大脑需要抓住它好得以继续坚持。

刚 Google 到的一篇文章： https://tusharf5.com/posts/js-promises-eager-not-lazy/

Promise != Lazy ，你需要的更像是 Lazy

Promise 构造函数传入的 executor 函数会被立即执行。

简单的理解一下：

时间：某一个时间点绝对值
时区：对时间点的修饰偏移

显然数据库存储的值不会根据你的时区是什么而发生变化，所以只能是在读取的时候根据当前已确定的时区进行不同的展示。

60 块钱的 CM311-1A ，2+16G ，S905X2 芯片，原生 Android TV 9 ，搭配路由器科学上网，可看油管

本来想买一个 S8+的，值得买 APP 最近搞活动返 500 的 E 卡，后来想了一下买来实在用处不大，就放弃了

我现在的第一想法居然是政策问题，还有你这个用户量如果上不来，缺少曝光度的话，就没有足够多的内容来为你的算法进行匹配。最后祝你成功！

问题不在于有哪些解决办法，而在你能承受什么样的成本。
你是想在屎山上继续堆屎还是来个大扫除为将来留下更多的操作空间？

现状就是你有几十张表需要去更新，在不考虑重构的前提下，你能选择的方案并不多：
1 、你想要在一个事务里面进行更新，这也是最简单的办法，但是你会担心说影响性能。
2 、一张表一张表的更新你又会担心无法保证数据的完整性。

如果是我的话，在没有重构的选择情况下，在没有了解业务领域的情况下，我会选 1 ，这也意味着我不会考虑系统的性能，也不会考虑到系统的可用性问题。

如果你是系统的设计人员，如果你有权决定是否应该重构，那么就应该考虑到这些问题（可用性以及可靠性）如何影响业务系统的架构设计，这些问题你应该最了解，如果你还不了解，那么要先去了解，因为只有你先了解以后，你才能够根据规模来决定应该如何重构，重构哪些方面可以解决关键的问题，以及重构的成本是否可以承受。

1 、如果你没有及时清理 ThreadLocal 中存放的变量，线程实例也没有销毁，那么当这个线程实例执行下一个任务时，如果任务中有访问到同一个 ThreadLocal 存放的变量，就会造成一些状态依赖问题，可能会破坏依赖这些状态的代码逻辑。

2 、一般线程池有一个缓存队列用来缓存任务，当有可用的线程时，就会取出队列中的请求交给线程执行，取决于线程池的相关设置和策略，这部分在创建线程池的时候都是可以设置的。相关介绍： https://www.baeldung.com/thread-pool-java-and-guava

3 、同上线程池可以是同一个实例（一组线程），也可以是不同的实例（多组线程），取决于配置。

4 、这个跟使用语言的框架有关，比如 Java 通常使用 Spring MVC 或者 WebFlux 等等，现在的框架数不胜数，不过我建议你最好看一下 HTTP 协议相关的内容。

5 、如果是 HTTP 协议相关的，《 HTTP 权威指南》值得一读，其实不一定要买书，很多在线的网站资源都能够系统的学到一些知识，虽然比较零散。

我已经很久没有关注这一块了，开源的可以选择的不多，基本上都是 Activiti 系的，Flowable 看起来比较活跃，Camunda 是魔改版，提供很多特性，国产的很多工作流引擎更加符合国内的审批流程。

如果是我的话，可能会选择 Flowable 来进行定制，不过最终这一块还是得自己多比较一下才能知道哪一个更适合当前的业务。

1 、工作流引擎实际上是没有用户这个概念的，工作流说白了只是一个状态机的实现，这个实现帮我们搭建了一个最底层的基本平台。我们所说的用户和审批只是在上面进行了业务封装而已。因此你可以设计一种数据结构来表示用户来自哪里以及他的一些相关的信息，然后将数据存放到流程实例当中。

2 、关于审批签名，这个属于审批流程的概念，比如“会签”与“或签”，还有转交、加减签、回退审批等等，同上，工作流引擎也并不知道这些概念，这些都是上层封装的，只不过审批的场景太过于常见，因此在工作流引擎和最终的应用之间，建立了一套审批的抽象和机制，所有实现这些抽象的数据结构和行为，都是需要预先定义的（自定义封装），然后提供给外部基于这些抽象的编程接口。

3 、工作流引擎的流程实例提供了一个上下文环境，可以存放各种的变量信息，你可以通过设定各种各样的变量和条件判断来执行逻辑以及分支跳转。但是不要忘了，你使用工作流的目的是什么？工作流应该仅仅只处理流程上的某一个环节通过与否，以及下一个环节的状态跳转。其他的完全可以通过外部的 CRUD 管理系统来提供更多的操作内容。因此需要外部应用与工作流进行集成。试想一下，如果没有工作流，没有审批，你如何实现这个功能？答案可能就是自己建几张表，然后提供一些 CRUD 的接口而已。

4 、同我说的第 2 点。

5 、同我说的第 2 点。至于回到申请用户那边，说白了也只是在流程设计里面有一个环节需要发起人来完成而已。