name标签上支持a。关于很长的答案，例如关闭/迁移指南答案，这将允许直接链接到特定的关闭原因。这样，当有人问为什么关闭问题时，这可以使我们直接链接到适当的原因和描述。
（这篇文章的原始版本是
name或id，但是偏爱name。我同意Koper的回答，我取消了支持id的想法，因为Koper的权利-太危险了。）#1 楼
我希望看到这一点，因此指向长帖子的链接可以直接转到相关位。对于FAQ，词汇表以及包含大量常规信息的帖子尤其有用。一个简单的实现是将标题和标题自动转换为命名锚点。如果您想在帖子中包含链接，只需使用标题即可。
这样就不需要奇数格式，这是特殊情况，并且仍会产生可读的markdown（markdown的主要功能之一就是markdown源是可读的）。
这是标题锚点（标题）
这将是一个锚点（标题1）
这将是另一个锚点（标题2）
这是第三个锚点（标题3）
这是第四个锚点（标题4）
第四个锚点的大小，粗细，重点和字体与普通文本几乎相同，因此如果需要，可以“隐藏”文本的锚点他们不希望标题很明显。它仍然必须保持自己的路线，但是总比没有好。
此外，与它们的链接将非常好-它们具有标题。
解析器可能需要替换带有下划线
_的空格，删除无效字符并添加一个单调的数字（因此该页面不会以相同名称的多个锚点结尾），但是总的来说，这似乎是相对容易实现的事情，并且作为奖励，与现有的markdown文件向后兼容-只需将它们重新解析为HTML，即可将任何现有的标题转换为锚。评论
我真的很喜欢这个实现想法。超级干净。
–约翰·鲁迪（John Rudy）
2010-2-23在20:43
以后编辑答案以更改标题，在帖子中更早添加另一个标题或将其从h1更改为h2时，会发生什么情况？在我看来，您希望允许答案作者指定ID，以便他们在以后的编辑中明智地选择是保留还是断开锚点链接，但是会自动为元素的ID加上答案ID以避免冲突。以及页面上的其他ID。
–马克·阿默里（Mark Amery）
2014年1月29日11:26
链接到脚注也很不错，而不仅仅是点击标题。我只是建议一个彻底回答问题的人这样做，我可能发誓我以前见过，但是我认为这只是关于meta的CW风格的大问题。
– Peter Turner
18年1月25日在15:46
我有一个执行此操作的用户脚本（但仅适用于已安装它的用户）：stackapps.com/q/7994/9011
–塞缪尔·刘（Samuel Liew）
19年12月12日在12:31
如何处理重复的标题字符串？我认为锚名称必须唯一，不是吗？
–auspicious99
20年6月8日在5:14
@MarkAmery锚链接是HTML不可或缺的一部分，因此无法正常运行。如果移除/更改了锚，则您具有当前行为-指向页面的链接。链接的相同准则适用于锚点链接。 E.我尽量不要将链接隐藏为动作。 w3.org/WAI/tips/writing/#make-link-text-有意义
– dotnetCarpenter
2天前
#2 楼
我也赞成。我想知道命名锚的标记降价是否会比HTML更有用？例如：
[Link From ver 1][1]
[Link From ver 2](#target)
.
.
[Link To][#target]
.
.
[1]: #target
评论
这可能更适合于支持现有的Markdown基础架构。
– Der Kommissar
17年8月29日在16:14
#3 楼
我赞成，但不允许指定ID。如果有人选择一个已经在使用的ID，它甚至会破坏页面的验证，尤其是它也会破坏javascript功能。老实说，您很可能是唯一使用它的人，但仍然不会受到伤害，并且应该易于实现。评论
我同意我的身份，这是值得的。我可能应该更新问题以使其更加清楚。
–约翰·鲁迪（John Rudy）
2010年2月2日，下午5:47
如果您自动生成一个特定的前缀（答案ID本身？），它不会中断。
– BalusC
2010年5月12日23:01
尽管当前大多数SE网站使用HTML4（stackexchange.com本身不是），但其他网站可能使用HTML5中的数据。谁知道：总有一天SE可能也全都是HTML5。对于HTML5，已过时，即使以某种方式存在，它也必须是唯一的，并且不能与任何id匹配？
– Arjan
2011年4月23日在7:51
+1 Stack Exchange可以根据每个答案自动将ID散列为唯一值...这将解决上述验证问题...就目前而言，它们已经在处理div ID，如该答案所示
–迈克·彭宁顿
2012年8月22日10:56
#4 楼
并不是为预先指定的锚点ID设置新的Markdown语法不是唯一选择。 />还没有HTML的标准。但是其他文档类型已经允许片段标识符用于搜索/深层链接。 PDF例如
#search=text，文本/纯文本至少#line= 120,130 如果仅根据URL精确定位网页（也应该如此），它将使网络使用者受益并减轻文档作者的负担。
给出一些实现和语法示例：
#findhash（用户脚本）使锚点的存在变得多余。在没有指定的DOM name =或id =的情况下，它仅搜索文本内容。#~search+word（用户脚本）是我写的。它添加了~前缀以区分普通锚ID。而且~看起来像是一堆搜索内容，或者至少让人联想到Perls regex搜索=~运算符。不适合SE。虽然DOM遍历方法是SO的主题；我们的问题/答案通常会轮换（投票），而不必理会经常变化的布局。因此，它比文本搜索锚更加脆弱。或者让我们来弥补一下：
#!s!design 无论如何，它只是几行jQuery。将有利于外部引用。而且，我们不需要合成或手工制作的锚ID堆。
通常例如从技术上讲，Stackoverflow问题与解答是简洁的，其中＃answer-12345锚点就足够了。
但是我们也有很多非常详细和权威的参考答案；自然更长。并且提供URL＃search-FI支持将吸引旨在链接到这些URL的对象。
同样，如果SE决定采用合理的语法，那么人们可能会希望这种流行。即使只是在每个网站上实施以代替WHATWG的利益。
#5 楼
我不同意接受的答案，但我正在回答，因为建议您使用它来吸引人们关注功能请求。截至本文，问题已经9岁，当时98岁赞成-仍然没有状态标签，也没有指示是否将要实施的标志。特定问题而无需重新发布信息。
MediaWiki（Wikipedia的开源版本）具有此功能，并且我已经在专业环境中使用了它，从而发挥了巨大作用。它允许在站点的其他部分“复制”单个信息源。将来对源所做的任何更改都会自动反映到所引用的所有位置。链接不是很好，但是它仍然是朝着正确方向迈出的重要一步。我们可以获得状态或回应吗？
#6 楼
我想专门为脚注提供临时解决方案，因为它可以与一些较新的浏览器版本一起使用，并且不会崩溃和烧毁。如果要提供脚注，我们可以执行以下操作：
Blah blah blah[<sup>1</sup>]
Blah blah blah
Blah blah blah
Blah blah blah
Blah blah blah
---
1. This is my footnote... (b3m2a1Footnote1)
[<sup>1</sup>]: https://meta.stackexchange.com/questions/37894#:~:text=b3m2a1Footnote1
"This is my footnote..."
呈现类似
Blah blah blah1
Blah blah blah
Blah blah blah
Blah blah blah
Blah blah blah
这是我的脚注...（b3m2a1Footnote1）
说实话，这非常脆弱，这全取决于您的浏览器搜索效果如何，但仅针对单个Q / A帖子（我发现自己所做的大部分事情）效果很好
评论
好主意，尽管我似乎无法在SO上使用它，并且上面的链接对我也不起作用（Chrome）。如果我在浏览器地址栏中手动输入“相同URL”，它确实可以工作（有时）吗？
–怀特先生
20 Sep 23'0:06
评论
+1我很想知道为什么未实现此功能3年，这还没有实施？ Github允许这样做，非常适合编写文档。我应该指出，Stack Overflow上的PHP标签有很多参考文章，这些参考文章很长。允许锚点不仅将简化链接过程以将重复对象微调至相关部分，而且还允许制作目录，以便于导航。请为此添加支持。
用户链接到未定义名称的点的可能性如何？这会导致不方便地生成文本/代码吗？
@ Shog9我希望添加此功能。
太棒了特别是用于FAQ帖子之类的东西。
既然文档即将失效，这又是非常相关的-能够创建到很长答案的特定点的规范链接（特别是在许多点很大且很重要的情况下）将非常有帮助（特别是在代码审查上）。特别相关。
@EBrown：我也想要锚链接。主要问题是我们需要在Markdown中发明一种新的方法来做到这一点。有关几种可能性，请参阅CommonMark论坛上的讨论。将空链接定义转换为锚点是另一种可能性。但是由于答案共享页面，因此如果两个作者偶然使用相同的锚名称，则需要一个功能规范来处理不同的锚。
@JonEricson我实际上在Code Review网站上提出了URL语法的一种变体（很早就看到这个问题或CommonMark讨论了），如果开括号后面的第一个字符是井号（＃）并且它是字母数字+-仅，然后将其设为Anchor标签。这完全符合当前的URL语法，甚至还允许您在非标题元素上定义它们。
@JonEricson如果帖子ID是URL的一部分，则IMO解决了相同锚点名称的问题。我认为最大的挑战是处理修订系统，该链接可能在rev.2中存在，而在rev.3中消失了。
@ Meta'sMug：是的。但这带来了可用性困难。如果要使用内部链接，则很难/不可能在编写帖子时预测PostId。然后，我们需要弄清楚锚点是否存在以及名称是什么。与Markdown更改一样，我们还是不愿意突破发明语法。
@JonEricson为什么需要更改语法？如果我执行###某些标题，那么提供ID而不是用户的ID是渲染器的工作。我认为，与更改语法本身相比，更重要的是更改现有语法的呈现方式，就像当前投票最多的答案所暗示的那样。预览框不需要实现（导航预览链接将始终离开撰写的帖子）
@ Meta'sMug：嗯...好像我们越依赖系统使链接起作用，GUID系统比让用户指定ID的任何部分都更有可能。