说下我几年前的一个需求情况和解决思路，看看能不能有所启发吧
当时公司做一套答题，题库大约 5k 条，每轮答题给 10 条数据，同一个用户只要显示过的题目后面就不再出现。
我是先把题库入库，然后写了个算法，核心是利用用户的 uid 作为 seed 丢给 java 的 random 函数，从而给每个用户生成一个独一无二的随机序列，再利用这个随机序列对题库做映射，这样每个用户都能实际确定一个答题顺序，然后每次答题，只用记录答题的轮数，访问答题接口时只要传 uid 和轮数就能先快速在程序中算出需要的题目 id，然后数据库 select in [ids] 就可以了

@debuggerx 看错了，ddns 啊，我是本来就有域名，然后用的 ddns-go 这个项目做的自动更新。没有域名的话，免费的花生壳或者 no-ip 也都是可以的

@jaTomn 我是在内网的一台服务器上部署了 AdGuardHome，然后在路由器上设置了 dns 为这个服务，然后通过 AdGuardHome 的管理页面添加的 dns 解析，这样内网连接的设备都会自动走这个 dns

@jaTomn 我之前就是在内网无法通过公网 ip 访问服务器，所以才说应该是一样的情况。我的情况是，光猫拨号得到公网 ip，其自身的内网 ip 为 192.168.1.3，然后直接 dmz 到下面的路由器，路由器和内网服务器的网段为 192.168.31.x，再在路由器上设置端口映射对应每个内网服务。之前的情况就是在内网里，我可以通过 192.168.31.x 访问某个服务，也可以通过访问 192.168.1.3:port 访问，但是公网 ip:port 在外网是正常的，内网却不行

如果我没理解的话，应该和我的情况一样……我的解决办法是利用 ddns，公网上 ddns 解析成公网 ip，而在内网中通过静态路由或者自建 dns 服务器将 ddns 域名解析成光猫的 ip，从而实现不管在内网还是外网，都可以通过域名进行服务器访问

11 年大一买的第一台笔记本，12 年去售后修过一次，留下了很不好的印象，从那以后都是自己修，自己的修完给同班修，最后甚至修到了其他专业……常见的问题基本就是换，换屏幕换硬盘换排线换网卡，没啥技术难度，目前为止最难的一次也不过是动手焊了个 BIOS

居然没人提 stylish 自定义页面样式

因为很有可能其实并不需要“开发自己的 app ”……
1.有可能你想要的东西实际上是有的，只是你没找到——善用搜索引擎，逛逛 github 和 play 市场
2.有可能你的需求并不需要用 app 实现，可能只需要写个网页然后加个桌面书签，可能只是一段脚本放在 Termux 中执行，甚至可能只要下个 Tasker 就能解决
3.可能你是想业余时间学 app 开发拓宽财路，但是后面会发现市场上需要原生 app 开发的项目越来越少，小程序、跨平台等等越来越多地侵占了原生市场……
所以我说，能不学就不学，过来人表示学 java\kotlin 的投入回报比是越来越低了

能不学就不学 有空学点其他更有前景的技术不香么

推荐首歌《手紙 ~拝啓 十五の君へ~》: https://music.163.com/#/song?id=550661

……
自分とは何でどこへ向かうべきか 問い続ければ見えてくる
——自己要走向何处，这样的问题只要走下去就会知道答案的
荒れた青春の海は厳しいけれど
——无所适从的青春就像是从海上乘风破浪
明日の岸辺へと 夢の舟よ進め
——要乘着梦想之船向着明天的彼岸进发
今 負けないで 泣かないで 消えてしまいそうな時は
——现在，到了要认输、哭泣、消失的时候
自分の声を信じ歩けばいいの
——只要相信自己的声音一直向前就可以了
大人の僕も傷ついて眠れない夜はあるけど
——即使是长大的我也会因为心碎彻夜无眠
苦くて甘い今を生きている
——苦尽甘来的活在当下
……

十年前高中那会儿偶然在电视上看了第 60 回红白歌合战，第一次听的这首歌，瞬间泪奔
至今觉得那一次的红白最棒，很多歌听到现在：
生物股长《 Yell 》
水树奈奈《深爱》
ジェロ《海雪》
FUNKY MONKEY BABYS 《 Hero 》
……

@JerryCha
@lylsh1993


特性再好，浏览器都不支持怎么用

代码约束 +10086
口头沟通的成本总是最高的

@xy2401 屁股决定脑袋，iOS14 能支持 webp 已经是谢天谢地谢库克了……
但是看下 iOS13 及之前版本的占有率：

https://i.loli.net/2020/11/24/nxmGBjlrwFyUoef.png

emmm 。。。

@murmur 不是很懂你的逻辑，Flutter 又不是要替代 h5 的，我现在给公司写的 app 就是主体部分 Flutter， 动态部分 webview，h5 用的技术栈是 Next.js + ts + Material-UI 。前端技术栈里我最推崇的就是 react，但是在移动端跨平台这个场景下，rn 确实和 Flutter 没法比。
对我个人来说，哪怕需求就是只做移动端单端(android/ios)，我也更愿意用 Flutter 而不是原生，就在于它的开发体验和开发效率比原生好太多。
我觉得应该在合适的场景用合适的技术，而不是各种场景都想着用自己熟悉的技术。比如以前 java 开发用 jsp 写页面，比如 php 开发用 php 写运维脚本，比如用 css 写桌面环境……

@murmur 个人体验是，原生 app 开发学 react 会一脸懵逼，入门门槛很高；
学 Flutter 门槛稍低，既可以复用一部分原生的知识和思想，也得以有机会了解前端的思想；
已经会了 Flutter 再学现代化前端，就是看下文档熟悉几个 api 的事儿，毫无难度。

@HuHui 不用怀疑，是 flutter/dart-lang 的锅。。。
最近他们的开发团队真的拉跨，不知道是不是 PM 的 KPI 问题导致，新功能加了不少，基础设施和功能各种崩，先是代码提示废，然后是 as4.1 更新后 flutter 环境不识别， 还有一次语法更新 '@required' 变更为 'required'，结果语法检查就不通过了……

@janxin 是的，Widget of the week 我也看，官方出品质量保证。
再推荐一个博客，经常能看到最新最炫的东西：
https://flutterweekly.dev/archives/
个人感觉， 学 flutter 最好的时间一个是 18 年底，一个就是现在，否则可以预见等到它继续发展进化下去，早晚也会变成像现在 android 生态一样的一大坨，大量的学习精力都要浪费在走弯路上

其实，现在的体验已经没有一开始好了……
我是 18 年初开始玩的 Flutter，那会还是 alpha 版，开发体验爽得不行，爽主要体现在：
1. sdk 源码很简洁，结构很清晰，虽然有些 bug，但是很容易追源码，有问题的地方可以自己改
2. dart 语法简洁，多数场景下都有几乎唯一的写法，很少骚操作
3. 代码提示逆天，当时的 dartlang server 代码提示效果极好，多数情况下即使是没用过的组件和 api，单靠代码提示就能写得下去

而发展到现在，Flutter 确实修复了很多 bug， 增加了很多特性，生态和资料也多了很多，但是日常开发过程给我的体验反而是退步的，与上面逐一对比：
1. sdk 代码量膨胀，增加了很多组件，官方文档却跟不上，有时难以找到需要的组件，有些组件代码很混乱难以使用调试
2. dart 语法迭代，增加了不少新的语法糖，虽然确实在某些场景解决了一些问题，但也导致了一些情况下写法的不一致，增加了出错的概率和理解的难度
3. 目前 flutter 的代码提示几乎是废的……参考这个 issue [https://github.com/dart-lang/sdk/issues/43657#issuecomment-724590463]( https://github.com/dart-lang/sdk/issues/43657#issuecomment-724590463) ，他们想实现"更好的"自动导包，所以对 dartlang 的 lsp server 进行了大改，结果破坏了原本的智能提示类型排名，现在提示出来的类型列表几乎总是无关的东西排在最上面，甚至连 String 这样的基本类型都要一个一个字母全部打完，提示都还在找各种包里所有包含 "string" 这个字符串的定义，可以说是非常难用了