我搜索了Emacs Git存储库中的所有Emacs Lisp文件，发现(goto-char (point-min))发生了3621次，(goto-char 1)发生了31次。就我个人而言，我看到很多，(point-min)但没有1，即使在很多情况下，也可以100％确定该区域不会缩小。因此，这是我的问题：与未缩小的缓冲区(point-min)相比，它仍然是首选的1吗？

我猜1比(point-min)它快，没有多大，因为函数调用时1是常量(point-min)。此外，1比短得多(point-min)，1个字符对11个字符。

您怎么知道缓冲区没有缩小？

除非在调用函数之前就已将其扩展，否则无法确定。此外，“优质软件”通常被定义为“以作者从未想过的方式使用”-因此，应始终为不寻常地使用自己的代码做好准备。

代码可读性为王

当您编写(goto-char 1)代码时，阅读代码的人（包括6个月后的您）将花费宝贵的脑力思维

• “我们怎么知道缓冲区没有缩小？” 和
• “第一个字符是0还是1？”

基本上，除非您有(widen)正确的选择，否则您需要添加注释以解释为什么您确信缓冲区不会变窄。

成本微不足道

除非您已对代码进行了概要分析并找到了其他方法，否则安全的假设是这里的成本将是微不足道的。与ELisp所做的所有其他事情（网络，磁盘访问，甚至字符串匹配）相比，它(point-min)不会产生可观的成本（甚至可能更便宜，请参阅Stefan的答案）。

尽管有出现，但作为sds的答案（我完全同意）的补充，(point-min)它可能比效率更高1。在执行速度方面，我的测试没有发现任何可测量的差异，但是在大小方面：

ELISP> (byte-compile '(lambda () (goto-char (point-min))))
#[nil "eb\207" [] 1]

ELISP> (byte-compile '(lambda () (goto-char 1)))
#[nil "\300b\207" [1] 1]

ELISP> 

那是因为point-min它有自己的字节码，因此与其他函数调用相比，编码和执行效率很高。

当然，我使用的另一个原因point-min是，我认为历史记录的选择1是错误的（缓冲区应该从0开始）。