对上条回复的补充，如果你配置了 tslint，你在 await 那一行会收到警告

'await' has no effect on the type of this expression. ts(80007)

这里 no effect 并不完全正确，因为他的确会存在潜在的执行顺序变化

对以上两个回答都不敢沟通，给题主一个简单的测试环境
async function test() {
let cb = () => {
Promise.resolve().then(() => console.log('awaited'));
};

await cb();
console.log('after await');
}

test();

以上代码加不加 await 对运行结果是有差异的，分别为，
添加 await：awaited，after await
不添加 await：after await，awaited

究其原因是因为当你给一个 function 添加 async 关键字并在其中使用 await 之后，此处就会产生一个 asynchrony context，所以以上代码最后可以理解为以下的等价代码（仅供参考执行顺序，并不完全严谨）
Promise.resolve()
.then(() => {
let cb = () => {
Promise.resolve().then(() => console.log('awaited'));
};

cb();
})
.then(() => console.log('after await'));

所以题主的理解“ await 后面跟一个函数执行(没有返回 Promise 以及没有 then 属性), 应该是直接返回值, 语义上不应该对执行顺序产生影响”并不完全正确

个人开发者，学校期间帮导师上架了几款导师业余想做的文学类目的 app 都没啥问题
目前工作了，业余时间做的游戏（主要分类是游戏）也通过了 test flight 的 beta review，根据官方所说和正式审核要求几乎一致
体感下来应该没啥限制

追求简单的话可以看看这个
https://git-scm.com/book/zh/v2/Git-工具-凭证存储

不顾虑密码在本地明文存储的话直接用 store 就行了

哎，说句离题的感想。
这种系统只有在不知道的时候杀伤力最大，一旦暴露出来就没啥用了。毕竟摸鱼的方法有无数种，他还能放个摄像头实时监测我的表情不成。

@terrytw 好的，目前已经决定全部流量走 tcp 了（捂脸）

仔细想了想，这个问题是个伪问题。
既然担心 udp 丢包那么从一开始就不应该用，毕竟移动数据丢了，光有状态数据，这个游戏也根本完不成。

@terrytw 好的，也就是说实际效果还要根据使用时段不同，或者是地域不同还会有差别。有的时段非常好，有的时段就会很差？

@GreatHumorist C/S

感谢楼上各位大哥的回复，现在准备改成按流量计费了。核算下来确实比按带宽付费核算

@learningman 卧槽，那我要去好好看看了，反正也就只有审核的时候要用，平时流量应该不大

@hst001 哈哈私服可不敢碰，几个小伙伴一起做的小游戏罢了

@cepczkd 听你这么一分析，非常有道理。 按量付费总有点不敢，万一有人找事，那好像就爽了哈哈哈。

@windyland 好的，目前所有和游戏有关的内容都托管在 github page，国内服务器上不会提供 web 服务的。

哎带宽可能先用着小水管吧，等以后万一玩的人多起来了再多买点带宽。

@CEBBCAT 哈哈游戏受众群体小，我估计大部分人会觉得不好玩儿。等有模有样了再放上来和大家分享。目前服务器还没有啥需要备份的内容，数据都在内存里没啥持久化的需求。

听你这么说我觉得还挺安全的，等有时间了我去挑挑香港的云服务器厂商，目前选在大陆主要还是贪延迟比较低。

@coolcoffee 说到 dns 解析，感觉还蛮复杂的。这几天在为苹果的 review 做准备，还要保证在纯 ipv6 下也能成功解析，并且能成功连接，想到这个就头大

@PureWhiteWu 哈哈，那可能是神奇的打错了

@PureWhiteWu 这个首先看什么是 normailze，一般就是我们所说的数据库范式 1NF，2NF，3NF，BCNF，一步一步上升的过程其实就是 normalize 的过程
这里可能（我的猜测）会指的是，如果非常追求 normalize 程度，photo 自己一张表，photo 的 like 存一张表，两者通过 photo 的表的主键进行连接，在查找的时候通过 join 找到对应的 photo 的 like 个数
然后所谓的 denormalize 就把 photo 的 like 直接存在 photo 的表里去了，这样就可以减少数据库层面上的查询开销

的确是个好项目（好的 idea ），而且做得好的话对于公司的价值会远比对于个人的价值更大。
如果单纯是个开源项目的话，骨架倒是还好搭，之后肯定会存在大量的“脏活累活”需要去适配，收藏一下，以后保不准有用得到的地方。