关于附加组件，扩展和插件应该查看这个答案。但总的来说，你似乎有正确的想法。

问题是，目前有三种不同类型的扩展：

1. 经典扩展（不能重新启动）：这些扩展将通常覆盖浏览器窗口并从这个覆盖层运行代码。由于每个窗口都有一个覆盖图，所以会有与浏览器窗口一样多的代码实例。但是，经典扩展也可以通过注册一个XPCOM组件（） chrome.manifest 截至Gecko 2.0 ）。该组件将在首次使用时加载，并留待整个浏览会话。您可能希望在浏览器启动时加载组件，为此，您应该在 profile-change-> 类别中注册，并实现 nsIObserver 。


2. 重启扩展，也称为引导扩展：这些不能注册覆盖，这使浏览器UI的工作稍微复杂一些。相反，它们有一个 bootstrap.js 脚本，当扩展被激活时，这个脚本将被加载，这个上下文将保持在后台，直到浏览器被关闭或者扩展被禁用。您也可以将XPCOM组件放在不重新启动的扩展中，但您必须手动注册它们（通过 nsIComponentRegistrar.registerFactory（）和 nsICategoryManager。 addCategoryEntry（））。如果分机关闭，您还必须注意取消注册组件。如果你只是需要添加一个观察者，这是不必要的， nsIObserverService 将采取任何实现 nsIObserver 的对象，而不仅仅是一个已被注册为XPCOM组件的对象。最大的缺点是：大多数MDN示例都是关于经典扩展的，并不解释如何在无重启扩展的情况下做这些事情。 基于附加SDK ：这些基于一个产生重启扩展的框架。附加SDK有其自己的API ，它是和你通常在Firefox扩展中做的很不一样 - 但是它很简单，而且大部分都是关闭扩展，所以你不必手动完成。这里的扩展由一些模块组成，其中 main.js 自动加载，并且可以根据需要加载额外的模块。一旦加载，只要扩展处于活动状态，每个模块都会停留。他们运行沙盒，但你仍然可以离开沙盒直接访问XPCOM。不过，您可能会使用内部 observer-service 模块而不是
   

I'm trying to write a Firefox extension that intercepts a certain HTTP request and return static content without the request making it to the actual server (similar to AdBlock).

I've looked up the tutorials and I've got a basic file layout. I've also worked out that I need to use the nsITraceableChannel API and add an observer to do what I want and I have example code for that.

Problem is, where do I actually put this code? And when is my extension actually loaded and executed? Is it running constantly and asynchronously in the background or is it loaded per page view?

The documentation doesn't seem very clear on this. This extension won't need a GUI so I don't need the layouting XUL files (or do I?). I tried writing some XPCOM (I don't think I did it right though) component, registered it in chrome.manifest but it doesn't seem to run.

Can anyone explain exactly how the Firefox extensions work and where should I put my actual JavaScript code to monitor requests? Or have I got the whole idea of what an extension is wrong? Is there a difference between add-ons, extensions and plugins?

Concerning the difference between add-ons, extensions and plugins you should look at this answer. But in general, you seem to have the correct idea.

The problem is, there are currently three very different types of extensions:

1. Classic extensions (not restartless): these will typically overlay the browser window and run code from this overlay. Since there is one overlay per window, there will be as many code instances as browser windows. However, classic extensions can also register an XPCOM component (via chrome.manifest as of Gecko 2.0). This component will be loaded on first use and stay around for the entire browsing session. You probably want your component to load when the browser starts, for this you should register it in the profile-after-change category and implement nsIObserver.
2. Restartless extensions, also called bootstrapped extensions: these cannot register overlays which makes working with the browser UI somewhat more complicated. Instead they have a bootstrap.js script that will load when the extension is activated, this context will stay around in background until the browser is shut down or the extension is disabled. You can have XPCOM components in restartless extensions as well but you will have to register them manually (via nsIComponentRegistrar.registerFactory() and nsICategoryManager.addCategoryEntry()). You will also have to take care of unregistering the component if the extension is shut down. This is unnecessary if you merely need to add an observer, nsIObserverService will take any object implementing nsIObserver, not only one that has been registered as an XPCOM component. The big downside is: most MDN examples are about classic extensions and don't explain how you would do things in a restartless extension.
3. Extensions based on the Add-on SDK: these are based on a framework that produces restartless extensions. The Add-on SDK has its own API which is very different from what you usually do in Firefox extension - but it is simple, and it mostly takes care of shutting down the extension so that you don't have to do it manually. Extensions here consist of a number of modules, with main.js loading automatically and being able to load additional modules as necessary. Once loaded, each module stays around for as long as the extension is active. They run sandboxed but you can still leave the sandbox and access XPCOM directly. However, you would probably use the internal observer-service module instead.