zephyru

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

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

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

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

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