部分才怪，我上次骑自行车走了机动车道（前面修路，占了机动车道），被交警拍照罚款 50

不大靠谱，只能玩玩，很容易断掉，另外内存太小，磁盘容量也不够，就是给科研者的玩具。

CPU 密集任务你看加再多线程，加再多内存也没啥用。I/O 密集型，使用线程池就够了，反正 I/O 线程也不会被 CPU 调用，设个大点的数量就好了。你给的条件太有限，给不出你优化意见。

@89ao 请先吧你的需求写清楚，一上来就这对自己不了解的东西发表吐槽，我只能这么回复你了。
微软的文档写的非常详细，虽然中文基本也是机器翻译，但该有的都有。
自定义仓库事件非常简单的事情，半个小时搞定，想要别人给你解决方案的时候，麻烦将自己的需求搞清楚。
https://learn.microsoft.com/zh-cn/nuget/hosting-packages/overview
https://learn.microsoft.com/zh-cn/dotnet/core/tools/dotnet-add-package

你整个问题我都无力吐槽，NuGet 是我用过的所有包管理里面最好用了，没要之一。

高三晚上第三节晚自习下课后，休息 10 分钟，用百米冲刺跑去食堂，然后 2 分钟旋完一碗面条，然后跑回课堂上第四节晚上自习，然后我吃饭的速度到现在都是那个速度，一个人吃饭从来不超过 10 分钟，后来就得到了胃病。

到现在我的电信手机还没恢复，昨天一个下午收不到短信，公司的所有账号验证都是绑定到电信手机号的。刚刚客服电话打了 1 小时还是没打通。

这个二逼的设定终于可以关闭了，恨透了这个功能，我操作的很多软件都需要鼠标精确移动，不知道苹果是不是有坑，强制启动这个鼠标平滑的设定。

基本的不需要 Debug, Debug 也是跑 UnitTest/Log/端点单步调试, 任何工程性质的项目都不会使用 ipynb 这种模式，这个模式只是提供给交互场景这种及其有限情况下使用的。

@tempw 售后和色准，主要就这 2 个，另外戴尔的做工很差，还不如小米。

@jaredyam iframe 之间又不是不能通讯，直接用 postMessage 通讯不行吗？走后端你请求的资源又不一定是纯文本，如果是纯文本，可以在 nginx 用脚本包一层，但是静态二进制资源你怎么搞？还有响应本身就是 2 部分：body+header(cookie 也在 header 里面), cookie 也可也定向禁用嘛，并需要禁用掉所有 cookie. 你这个方法本质上就有问题。你应该提供更详细的需求场景。

@Nem0 太卡了，mac m2 和 12700 都卡，怎么搞的。

@nullcache 我两个都用过，我曾经也是个小屏幕死忠党，12 mini/13 mini 我都买了，mini 的手感和质感都是非常优秀的，感觉是 iphone 4S 后最好的，核心问题就是 2 个：续航和发热，其次是双卡问题。作为一个主力机的话，你只要出门就会担心没电，因为真的续航无敌差，属于基本一天需要两冲的，我在公司放了个无线充电板，回家以后还要冲电。我现在只有出门跑步会使用 13 mini, 不过我今年买了个 watch se, 这样跑步接电话和听歌就不需要带手机了，对小屏手机的最后一个需求也消失了。另外我并不是手机的重度用户，不用手机玩游戏，也不看视频，就是刷新闻，常用手机 APP 不超过 20 个，用 mini 都觉得电量不够，你可以自己评估一下。显示内容也非常局促，反正各方面使用体验都不好。唯二的优点就是小和手感好。买标准型号的 iphone 就行，plus/pro 太大，pro 又太重。反而标准版最均衡。

为每个算子策略提供 factory, 每个策略有自己独立的 Factory.

无敌垃圾的续航，不建议买，除非有很多部手机，否则我不推荐任何买 iphone mini 系列。用过 12/13 mini 的说，现在换了 14 pro, mini 正常使用，大概重度使用不会撑过一个上午，你早上出门，中午就要找地方充电了。发热也非常严重，没有双卡，除非是终极小屏死忠，还有一个大屏手机做备用机。

没什么好办法，如果没有模型原代码，只能用数据走一遍，如果前向传播时候传递的参数非常复杂，你甚至可能没法尝试出结果。我一般分析模型也是用 netron, 但是 ONNIX 对 pytroch 的支持还是有问题。

Web, 不用刻意减少嵌套，只要记住标记应该是内容，而不应该是为了添加某个样式而构造，有了 flex 后，Web 的嵌套以前没有以前那么变态了。

这种事情，直接打电话给客服 400-880-0599 登记一下。
一段时间后没有修正反馈，就换个软件好了，说明这个 bug 在他们内部优先级很低。
这种 to C 的软件，你一个普通用户，对他们说啥也不是。
国内很多 APP 的 bug 你提反馈，人家都懒得回复你，你唯一能做的就是用脚投票，不要使用它这个应用。

当然是应该将异常传递给最终 SDK 的消费者，主要是看异常是谁制造的，谁制造的交给谁处理。因为异常就是个简化的通知机制，如果你尝试糅合异常和 Result 这 2 种消息传递机制，只会给自己制造更多痛苦。如果调用方是最终消费者(无法理解你系统的内部逻辑），那可以考虑返回返回一个稍微包装的友好异常。