不太必要...主要是没有那么多时间去钻研，不如先用起来再求甚解

这为啥水深火热啊...
OP 是想问啥？

这东西，没有什么绝对值...也没啥意思
锅在研发的话，那就是，研发在开发阶段没有全面的评估接口的影响面
想甩的话，那只能是，比如评审阶段没有人提出来

锅在测试，那就是，测试没有从业务层面考虑到这几个接口会相互影响及时复测，或者没有全面测试
但，如果测试说了，这个迭代不进行全量回归就甩不过去（很少有小迭代做全量回归的）

锅在产品，那就是产品没有在需求阶段指出这些需求（接口）会有关联
比较牵强，但也不是甩不过去

其它还能把锅甩给，线上的错误收集/监控/自动测试体系，如果有，那就是没有及时发现问题/用例有问题/不完善
如果没有，那就是需要搞一套

不想在 App 写死，感觉最好还是，提供一个接口，返回 token 和上传地址，上传地址后端配置现在返回七牛云的，后续要换再换（别的七牛云或者本地上传地址），非要经过自己的服务器中转的确不是一个好法子。

@nyxsonsleep
b 的 js 工程 加载 c 的 ts 工程，只有声明文件，我估计 c 的工程没有 source map 吧
如果你要调试 c 的 ts 工程，需要调试编译后的 js 文件（需要 source map ）同时要找 ts 的调试方式
不同的 ts 版本调试方式也不一样
一般来说要么配置 vscode 的调试模式单独从入口去启 ts 工程，要么使用 ts-node, 总之和 node.js 多少有些区别

嗯？ --inspect 不满足需求么？

加 ts 封装（或者任何抽象吧）基本考虑的是维护方便，不想管直接 any 走天下也没什么区别...我觉得不至于套一层 ts 封装把工期拉长多少...

我习惯放在底部，但可能是全屏有啥问题，总是自动给我挤到右边去

@duxiansen 只要名字？这功能可能的确是写个脚本定时执行会简单些...从根目录遍历文件夹，然后随便找个自己喜欢的方式输出图片/文件，功能太简单了，反而很难想象会有软件专门做...

这种情况感觉就是，SaaS 中台或者叫业务层与底层服务的区分，后端不想有 UI 的业务代码入侵后端，从设计上考虑其实无可厚非，无非就是 UI 的业务逻辑在哪一层聚合的问题，BFF 层可以后端维护，也可以前端维护，可以写在服务端也可以写在客户端，无关对错只是一个策略问题，你要是有能力可以推进后端针对业务抽象一层出来也不是不行，不好推就自己抽象吧

我有的时候会粘贴不到 chrome 的页面里，地址栏都可以粘上去，也许是有什么奇怪的插件？但也不是一定会出现....

这工具看起来蛮实用的，进入 24 年我依赖 CloudFlare Tunnel 的服务经常断链，感觉是个很好的替代

@yjsp1919
是的，直接写 js ，最简单的莫过于在控制台里自动翻页，拦截请求/直接解析 dom ，收集的数据直接生成文件下载下来
经常做这种事情可以写成油猴脚本，不想自己写代码可以去找 chrome 商店里的插件
其它，无头浏览器或者各种全自动测试框架也可以做这些事情，不过那就杀鸡用牛刀的感觉了

如果只是收集数据（一次性的），这种可以直接在浏览器里写脚本，不少插件干这事的...

的确，这个自己玩玩还行，大规模抓取用 AI 辅助效率不高，当前成本还蛮高的...
与其让 Ai 解析 html 文本，不如让 AI 辅助生成解析用的函数...

@luckykelan
前端 RN 后端无所谓吧，但 next.js 是不太合适...想用 js 写就 express 或者 koa 吧，想写变种 java 就 nest.js 。
个人感觉 koa 写着更舒服，轻量，但 express 社区更活跃，插件/教程/问题好解决一些。