"局域网部署"和“数据长期稳定”是冲突项。你要先定义好什么叫“长期稳定”。

就算你用 NAS ，或者其它什么服务器，都免不了硬盘爆炸，泡水，断电烧了机器等问题。所以 IT 部门让你们上云，这样相对于自建解决方案来说更稳定一些。
至于安全不安全取决于你们团队的水平，技术和意识到位不管是云服务还是本地服务都很安全，意识不到位哪个都不行。没什么经验和意识的话，本地服务并不会比云服务更安全，大概率更加危险。
如果不需要“版本管理”功能，那就不要用 SVN ，Git 这种东西，更用不上什么 Gitlab ，完全没意义。

你可以先找台空闲机器开个共享，试用一段时间看看能不能满足需求，一样可以配置账户权限等东西。如果有一定的技术水平，或者 IT 搞得定，可以试试 TrueNAS 这类软件，配置更容易一些。
直接买 NAS 产品主要是提供一个更易用的配置界面，比如配置用户，网络规则，RAID 等等。实际上应用功能方面跟你自己弄个共享差不多，反正大部分文档预览你们也用不了。先确定对于项目组来说功能够用不够用再说。

担心质保就国行，U 盘解锁换服就是了。也就之前有一次版本升级临时禁用了解锁，不乱升级就没事。
不在乎质保的话随便买个便宜的就行，这玩意一般不容易坏。

每次看见这种卖好几年会员的，给我的第一感觉就是这玩意要跑路了。。。

@paramagnetic 我有 iPad pro 2017 ，那个笔插上去其实非常长，每次充电都怕它碰断了。
而且它这个也不是加个转接器就能解决的。那个转接器只是两边的母口，你还得带根 type c 的线。

@PrinceofInj 有些路口有查。大部分还是狭路相逢勇者胜，就看谁不要命了。
你在人行道上，绿灯往前走，左边右转过来的车都能顶着你膝盖往前蹭。

其实就是个低配交换机。

3 公里随便什么车都行。
路不好的话，推荐山地或者防刺胎，至少我的光头胎是不敢骑这种路的。
没地方放，或者只能停路边的话，可以考虑折叠车。折起来放公司更衣室也不占多少地方，不然买太好的车很容易丢。

做医疗系统的话，利用好半夜人少这段时间。
用个表记录对应关系，弄个定时器半夜的时候再改。
跟客户说好，因为修改患者对应关系很复杂，尽量不要瞎搞。一旦真的搞错了，那所有修改第二天生效。
只要能该需求那都不是问题。

如果我是 A ，那么有几种情况。
不想费事的话，就弄个代理。抢到了白赚一杯奶茶，抢不到是你运气不好。
想费点事的话，套个 fiddler 啥的，看着它请求要是没成功就一直发。

如果这个项目没有其它人贡献代码是没问题的。
你可以认为你贡献的那部分代码，在彻底替掉原始 GPL 代码以前都是双 License 发布的。
只不过在原始 GPL 代码完全被替换掉以后，你用第二个 License 替换掉了 GPL 。
但如果你有其他人贡献的代码，那你实际上是没有完全的 copyright 的，自然也就没权利变更 License ，除非你把他们的贡献都替换掉。

不值，还不如折价换个新的。

@fds 可以，SQLite 有 Online Backup API ，https://sqlite.org/backup.html
它的命令行工具就可以直接做 backup

单通道的话，也就心率还能准一点。想想心率能做啥吧。
比如可以通过 HRV 判断压力状况。压力大的时候自动给 PM 发消息延期。
或者判断醉酒情况，偷懒养鱼就给同桌报警。
也可以判断摸鱼情况，上班时间过高或者过低都给领导发邮件。

@Mithril typo -> 攻破

另外，所谓安全性更不需要考虑。

当一个人可以物理访问到你的机器时，你就可以认为已经被公婆了。

从这方面考虑，SQLite 的安全性远超所有其它数据库。

更别说 SQLite 你可以加密数据文件，但其实意义不大。能接触到数据库文件，说明也能接触到你的程序文件，更别说你这还是服务器，挂个 debugger 连内存都能 dump 出来。这种情况下讨论安全配置没什么意义。

不需要，SQLite 的性能其实很好。
之前测过单表两千万的库也就才 40G 的文件，性能一样可以接受。

而且备份极其简单，特别是你客户没有专业运维的时候，告诉他们下班停了程序文件复制一份就行了。

想要判断什么时候放弃，那就要想清楚你的程序的生命周期。在这个生命周期内，你打算支持多大量的数据，什么样的业务模式。
如果你的程序单机跑没法满足需求，那么可能数据库也要考虑替换。
如果你的程序单机足够满足需求了，没那么大负载也没有高可用需求，那么 SQLite 就是最好的选择。

有很多类似的
https://github.com/multiprocessio/dsq
UI Demo: https://app.datastation.multiprocess.io/
https://www.visidata.org/
等等
其实能直接跑 SQL 就足够了。。。

不建议直接啃。
如果你会写代码的话，可以找找教程用你熟悉的语言实现个简单的编译器。弄个 JSON 解析器，或者做个简单的 DSL 等等。遇到哪里不懂的名词去查或者直接翻书就行。
这样你对于编译这个过程有个直观的理解以后，再去啃就会容易很多。
而且你也能知道自己想要学的那部分，对应的是哪些技术。学起来也更有目的性。

@FstarKing 我这个就是从技术角度考虑的啊。
在这个场景下，从技术角度考虑，这根本不是需要解决的问题。

另外反作弊和反破解，网站的安全防护等等是一样的，都是成本问题，而不是单纯的技术问题。
你要反作弊，防护等级越高，本质上就是要把越多的计算移到服务端来做。但你就算只扔个瘦客户端给客户，也防不住输入模拟+图像识别。除非强制开启摄像头。

最简单的，每局游戏保存生成地图的随机数种子。然后用它作为请求参数后台验证。这个可以防止你直接构造请求，用微信的加密更好一些。
同时也可以用它在后台做个模拟器，让用户发过来每步的点击操作，直接重放判断是否通关。这个性能消耗也不算太高。

但要我是开发肯定哪个都不做，就定期登上去清理一下看不顺眼的数据。反正热度过去了服务器都不用续费的东西，还不如想想这么多钱要干嘛。现在这个状态，多写一行代码就算我输。