过去的 4 个月里我也有类似的情况，不过没这么严重而已。

@jo3yzhu 说的对。

我现在这样:
1. 少看手机（或小的屏幕）。不知道为啥看就感觉很累，感觉是把我自己塞进屏幕里。特别是，睡觉前 1 个小时不要看。
2. 早睡。不要晚于 11:00 。10:30 就差不多了。
3. 起来以后先活动拉升一下，呼吸一些新鲜空气。听音乐。
4. 重要事情安排在上午。

我的观点也是: 「不如花几千块雇个人」。

先尝试问如下几个问题:
（ 1 ）他们遇到的情况，是所有菜鸟驿站的情况，还是个例中的一个；
（ 2 ）是因为人的素质问题，还是菜鸟系统问题？
（ 3 ）如果是人的素质问题，能不能通过 换人（雇）解决
（ 4 ）如果是菜鸟系统问题，其他菜鸟驿站怎么解决的？如果都是全国的菜鸟驿站都混乱，趁早别做了。

另外:
（ 1 ）换了我，这个生意做，我就买快递柜来解决这个问题
（ 2 ）换了我，这 10 万快给他们。休息下做其他事情也很好。

先选国企的。估计 到 2025 年之前整体经济形势还是动荡。目前看你也是本着结婚去的，准备期间稳定一些更好。
至于 B 和 C 你看自己的选择吧。

@Jiangy 相对非常靠谱了。你买的便宜一些，这样出问题了也不会心痛。你买一个工具，拿这个工具好好写程序，好好赚钱。买太贵了你需要”供着它”，就完全走偏了。

我推荐去京东买一个二手的 Mac Mini ，做前端工作足够用了。用这个赚钱足够了。

依然使用 SQLite ，它的读写速度快，而且稳定性上要比其他数据库高出非常多。

因为 SQLite 是文件数据库，所以你没有必要把很多数据都 塞到同一个 SQLite 数据库里。你可以 ① 根据业务分类；② 根据数据的读写频率；③ 只读 还是 读写 把数据归类一下。使用多个 SQLite 数据库。

这个方案可能最优。

@dengji85 的思路 和我想的思路是一样的：

1. 建立一个 [新的系统] ；维护这些基础的数据。
2. 其他历史系统都是只读系统；只有 [新的系统] 是可读可写的
3. 定期（比如每 5 分钟）做一次同步。可以是 历史系统 来 “拉” [新的系统] 的数据；也可以是 [新的系统] 把最新的数据状态 “推 /写” 到 各个历史系统。

保留数据变化的 audit history ，这样如果有什么异常，可以直接通过数据马上看到。

今天要发布一个版本，才发现不能用了，这可用性有点弱...
https://status.azure.com/en-us/status

@ycookie 并不是完全无解。这个问题再那里都会遇到。分享一下我的建议：

（ 1 ）合约阶段
制定正常的作业合同时，应该房东的验收其实时间和结束时间。如果期间房东因为不能履行正常的验收责任（时间责任和验收责任）那么； a) 默认自动验收通过； b) 房东可以延后验收时间，但是每延后一天，需要赔付给您 x 元；

毕竟顺利交付是双方一起的努力。


（ 2 ）执行阶段
应该有合理的质量监控。如果质量出现问题，那么负责质量监控的人员要负责 50%（工作失职），包工头负责 50%（用人失职）。
将质量要求与施工人员第一天就谈清楚，并获得同意：自己做的部分如果因为各种原因质量不达标，在合理时间内需要改进。这个合理时间应该算到施工时间和施工费用里。超过这个合理时间的，施工人员自己负责（能力问题和态度问题）。
（ 3 ）收尾阶段
包工头不能太贪心，一个工程没结束就开始另一个工程。留一周的 buffer 时间收尾一下。

这样做虽然不能 100% 解决所有问题，但是可以改善绝大部分。

@tomczhen 如果没有你的留言，我默认都认同了主贴的想法「运营内容比较简单」。这往往就是我们的思维定式（定势）。感谢你提醒。我和题主不认识，单纯留言感谢你。

* 建议投资一个服务器
* 麻烦一点：静态化后，保存在 github 上，但是这样的话数据就公开出来了
* 亚马逊有 free tier，你可以考虑下 https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-free-tier.html

你使用 LeanCloud 折腾的时间，不如买个服务器...

同意 7 楼说的。如果你对 js 和 java 都比较熟悉，那么可以自己写一下。一些事件和返回的地方处理起来需要多用心。
如果你也不是使用 react native 的话，那么 https://github.com/turbolinks/turbolinks 这个项目应该可以直接解决你的问题。

独立 App 的话 3 万 UV 已经非常好了。

如果用户在国内，先把服务器搬回来，然后规矩的注册个域名备案。
其他的方式也可行，但是折腾的时间你不如用来做客服，做功能，或想盈利模式。

当然前提是服务器费用你愿意出的话。
方案 1 会比搬瓦工费钱，但是换来速度和体验，也挺好的吧。

@fihserman123

且不说美丑。
Java 的内部类设计有它自己的用处（而且挺好用还挺简洁的）。这个在日常的后端开发中（服务器）不容易看到，如果你接触一些类似 android 的开发，或者看下 android 开源的代码，你就会发现这么大的系统，把所有的类暴露出来是一种迷惑和污染。反而使用内部类，一个可以是逻辑内聚，达到封装的目的，另一个也不会暴露给其他 public interface 导致其他人需要看到这个接口的实现而并不需要用到。

Effective Java 是一本非常不错的书，可以读一下。里边有 non static inner class 和 static inner class 的说明和讲解。

昨天我也看到一些外国朋友分享了。唯一的确定就是手机上访问不友好，其他的都挺好的。

@shanyue9 你好，请问我可以用你的代码做一份英文的吗？给大连的外国人看。

有时候人生过的就是自己心里过得去。

短暂看来，貌似没意义。
或许有天你遇到一个好团队，大家配合很好。那时你可以同台竞技享受。而你目前身边的其他人，未必可以。

我们都有单纯的心。保持住也挺好的。