所以今天我在看到以下示例和模板后决定阅读一些关于 jquery 插件开发的内容：
CSS-Tricks.com 插件模板 Longpress.js
现在，我有以下问题：
@Css 技巧：
el，那个东西在哪里初始化？var methods = {//...}jQuery 文档假定的系统？@长按
mousewheel()方法绑定到插件命名空间？先感谢您
编辑：
楼下有人说这个可能太具体了。所以我尝试以其他方式制定它；插件开发的官方文档中是否存在应该以其他方式处理的问题或不好的建议？
我会尽力回答尽可能多的问题。
“官方” jQuery 模式只是一个建议。它说明了最佳实践，但不是确定的。就是说，太好了，我什么都没用。“主管”部分（就在代码的末尾）非常聪明。
这种模式最糟糕的方面是它把成员都放在$了命名空间和$.fn命名空间中。前者可以避免，例如使用 jQuery“官方”模式。
el是传递给$.yourPluginName()from的形式变量$.fn.yourPluginName()，并且依次表示调用插件的 jQuery 选择中的每个元素。
我不太明白作者如何满足插件的公共方法。
这是一个更好的模式。它将一个成员放入$.fn命名空间。其他一切都是“私人的”（保存在最外面的封闭中）。
不需要也不需要提供公共方法。
该mousewheel代码不是这样的插件。它可能更好地归类为“插件”。将mousewheel事件类型添加到 jQuery，因此元素可以mousewheel附加处理程序/命名空间/触发等，与“单击”、“鼠标悬停”、“鼠标输出”等方式相同。
为什么他有一个名为 el 的参数，那个东西在哪里初始化？
el是一个参数，不需要初始化。使用插件时传入。例如，将使用未附加到 DOM 的空 div 来$.yourpluginname($("<div />")[0])初始化插件。el
他为什么要添加对 DOM 对象的反向引用？
反向引用只是将当前实例存储在元素上，以便将来使用该元素调用插件可以引用现有实例而不是创建新实例。
为什么他不使用
var methods = {//...}jQuery 文档假定的系统？
因为我们作为第三方开发人员可以使用我们想要的任何结构自由开发插件。
另外，他为什么不使用 jquery 官方的模式？
见上一个答案
为什么他，即他的 mousewheel() 方法不绑定到插件命名空间？
可能是不好的做法，但最终由插件开发人员决定是否有必要。
这只是不好的做法还是更好的方法？
两者都不是，这只是证明我们作为开发人员可以使用我们想要的任何结构来开发 jQuery 插件。
我更喜欢在 jQuery UI 小部件系统下开发，或者使用可以轻松扩展/修改的结构，这样我就不会得到 n 个不同版本的 plugin.js。（jquery 文档中内容的修改版本）