@winterfell30 #38
你用二分法打日志的过程，就不如直接使用 debugger， 用 debugger 大概率只需要跑一次……
以及，你的二分法的日志点，其实就是你心目中使用 debugger 的断点位置。

在我的理解，你这样其实是在使用打日志的方式来进行 debugger 的工作。

如我前面所说，日志查 bug 是一个系统化的工程，不是在遇到 bug 的时候才开始的，而是从开发阶段就已经 “留一手”。
也正是因此，断点只能用一次，日志点可以保留，后续查用。

@wangxiaoaer
楼主在主贴里其实已经写到了其中一种获取方式：恶意扩展

查阅 Apple 的 “识别 MacBook Air 机型” 页面：
https://support.apple.com/zh-cn/HT201862

可知，从 2018 年 MacBook Air 更换为视网膜屏幕起，就改为了 USB-C 充电。

@guyeu #26
你可能理解的过于偏激了，楼主的标题其实有个关键词是 “XX 为主”

以 debugger 为主的处理思路，更多的适用于 “一次性” 故障，是为了解决 bug 而做的。

以日志为主的思路是一整套动作，要掌握好日志的输出粒度，以及日志的格式化方便查找等。
之所以推荐日志为主的处理思路，则是因为它具有更好的 “整体性”，能在解决 bug 之外带来更多额外的收益。


至于是否一定能够 “快速” 定位问题，其实影响因素很多：
对代码熟悉的人，也许能够更精确的下断点；但也许遇到多线程的问题就会比较难受。
日志写的详细的人，也许能够只看日志就确定问题；但也许遇到日志盲区就不得不走调试。

这其实并不矛盾，以 xx 方法为主只是一种倾向，而不是完全摒弃另一方。

之前因为类似的问题专门和同事沟通过，我一再强调，不需要使用的字段，一个都不传。

但确实还会遇到很多人为了图省事儿，一整个表直接发出来（毕竟这样方便，ORM 直接出结果）。

@Martin9
连续的页面的话，先点第一页，然后按住 shift 点最后一页

印象中在 预览.app 里可以直接把 pdf 拖出来来着

我有一台很旧的笔记本会出现类似情况，更换内存后解决

另外，如果只是希望携带 header 中的 Authorization 信息，也许可以使用 307

但是 307 的实现各个浏览器都有不同，不清楚是否会一并转发 header

https://username:[email protected] 看起来属于 HTTP Basic Authentication 的一个已废弃用法：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Authentication
拉到最下面，看：使用 URL 中的身份凭证进行的访问（已废弃）

提一个 BUG，应该是站长一时没注意到。

V2 之前有一个设计是：
即使一个人选择了 『隐藏主题列表』功能，他发在 『二手交易』节点的帖子依然可以在『交易信息』 分栏进行查看。

我刚才测试了一下，将帖子移入 『关闭交易』节点后，无法在 『交易信息』 分栏中查看。

这样就不利于交易前确认交易历史了，建议修改一下。

似乎不小心 @ 到了人…… 非常抱歉……

按道理来说，这是代码版本管理需要处理的事情，你只需要在 commit message 里写清楚对旧方法做了什么处理。

实际中，如果很希望留下旧方法的尸体，建议直接注释掉，而不是简单的改名。
这样可以明确的传达出本方法已经『废弃』，避免再生枝节。

当然你也可以使用 @Deprecated 注解进行标注，但是…… 不是每个人都会去看 warn