Tiddlywiki 在设计哲学上，倾向于 tiddler 是短小的、易于组合的；但是以我的使用场景，tiddler 往往可能很长，并且存在层级。这时候需要一个 tiddler 内的 TOC 来方便梳理内容的脉络，并快速检索、跳转。

看过 Tiddlywiki 的 Google Group，似乎实现这种 TOC 并不容易（讨论 1 2）。但是我又发现一个曲线救国的办法。

有一个 Chrome 插件叫 Smart TOC，安装后可以在任意页面显示当前内容的 TOC。这样你用 Tiddlywiki 时也可以借助它实现 In tiddler TOC。

作者在 这里 提到了对于 TOC in Tiddler 的看法：

That implies making sections behave exactly like tiddlers. That's problematic because it means that all the behaviours we've built for using and manipulating tiddlers need to be re-engineered to work with sections. In some cases that's extremely tricky.

For example, how would you make a location hash link to a section (eg http://example.com/#my-section-12)? There's no syntax within the location hash to identify the string as being a section name and not a tiddler title.

Another example, to use the $list widget to list all sections of tiddlers tagged bar would require us to be able to process section names within filters. That implies that sections would need unique IDs - once again, making them meet the definition of a tiddler.

Basically, TiddlyWiki is a mechanism for manipulating tiddlers. Everything about it is predicated on the idea of a tiddler as the smallest unit of content. Your requirements describe something else: a mechanism for manipulating sections of monolithic hierarchical documents.

他的说法值得参考，往往你在设计一个灵活的软件结构时，一开始打开的根基、一开始的设计会影响到后续的方方面面。比如在 Tiddlywiki 中，一个 Tiddler 应该是最小的有效信息单位；如果抛弃这个设定，那系统的一些其他设计会显得奇怪。这是作者不主张加一个 Section 概念的重要原因。