该场景下缓存jQuery对象是否有性能优势？我的测试结论为何相悖？

Great question—this is a common point of confusion for folks working with jQuery, and your test gives a perfect starting point to unpack what’s going on here. Let’s break this down step by step.

First: The Core Difference Between this and jQuery(this) #

• Inside the click handler, this is a native DOM element. It has all the standard browser DOM properties and methods (like this.id or this.classList), but it doesn’t have access to jQuery-specific utilities like .hasClass(), .tooltip(), or .data().
• jQuery(this) wraps that native DOM element into a jQuery object, which unlocks all of jQuery’s helper methods. The catch? Every time you call jQuery(this), you’re creating a brand new jQuery object instance—this is the tiny overhead we’re trying to avoid with caching.

Your Test vs. the Real-World Code #

The test you ran only compares assigning this vs. jQuery(this) and logging the results. That’s why you saw a small speed gap: creating a jQuery object does have a minimal cost, but in that isolated scenario, it’s barely noticeable.

Now look at the original code you shared—it uses the jQuery-wrapped element multiple times in both the if/else blocks:

• $this.hasClass('bookmarked')
• $this.data('id')
• $this.tooltip("destroy")
• $this.data('title', ...)
• $this.removeClass(...)
• $this.addClass(...)

Without caching, every single one of these lines would trigger jQuery(this) behind the scenes, creating a new jQuery object each time. By caching var $this = jQuery(this), we only create that jQuery object once and reuse it for all those method calls.

When Does This Actually Make a Difference? #

• For a single click on one element, the performance gain is tiny (we’re talking microseconds). But if you have hundreds of elements using this handler, or if the event fires frequently (like scroll or resize), those microseconds add up to measurable latency.
• Beyond performance, it’s a clean, consistent pattern. Once you get into the habit of caching jQuery objects when you need them multiple times, you avoid accidental redundant work without having to overthink it every time.

Wait—Could I Just Use Native DOM Methods Instead? #

Absolutely! If you rewrote the code to use native browser APIs instead of jQuery, you could skip the jQuery object entirely:

// Example using native DOM methods
jQuery('.loggedin.bookmark, .loggedin.bookmarked').on('click', function(e) { 
  e.preventDefault(); 
  const id = this.dataset.id; 
  if(this.classList.contains('bookmarked')) { 
    // Remove bookmark logic
    this.classList.remove('bookmarked');
    this.classList.add('bookmark');
    // ... rest of the logic
  } else {
    // Add bookmark logic
    this.classList.remove('bookmark');
    this.classList.add('bookmarked');
    // ... rest of the logic
  }
});

But the original code relies on jQuery-specific tools like .tooltip(), so wrapping this into a jQuery object is necessary to use those utilities.

Final Takeaway #

Your test was accurate for the scenario you set up, but it didn’t replicate the real-world use case where caching provides value. The original code uses the jQuery object multiple times, so caching it is a valid (and recommended) optimization that avoids redundant object creation.

内容的提问来源于stack exchange，提问作者Jonathan Guerin