如何在JavaScript继承链中直接调用基类Renderer的render方法？

我正在处理一条包含3个类的继承链：Renderer（基类）-> Mailbox（子类）-> MailboxInbox（最终子类）
每个类都有自己的render方法，子类重写了基类Renderer的render方法，但某些场景下需要直接调用Renderer类自身的render方法。现在遇到的问题是：当在Renderer类的createElementWithTextInside方法中执行this.render()时，并不会直接调用Renderer.render()，而是会沿继承链从末端开始执行：

1. MailboxInbox.render
2. Mailbox.render
3. Renderer.render

我理解JavaScript类继承基于原型链的原理，方法会沿原型链查找，但想知道如何避免这种行为，在需要时直接调用Renderer类自身的render方法？

试过在Renderer中保存__self，但最终它还是指向当前实例MailboxInbox；也不能用.bind或箭头函数，因为需要保留上下文。

示例代码如下：

class Renderer {
     
  get noResultContent() {
    const p = this.createElement('p', 'no-result-msg');
    const textNode = document.createTextNode('No result');
    p.appendChild(textNode);
 
    return p;
  };
 
  createElement(tag, className) {
    if (!tag) throw new Error('Tag must be passed!');
 
    const res = document.createElement(tag);
    res.classList.add(className);
    return res;
  }
  
  createTextNode(text) {
    const res = document.createTextNode(text);
    return res;
  }
 
  /**
   * 自动创建元素并插入文本节点
   */
  createElementWithTextInside(tag, className, content) {
    const el = this.createElement(tag, className);
    const text = this.createTextNode(content);
    this.render(el, text);
 
    return el;
  }
  
  checkIfDomEl = el => el instanceof Element;
 
  render(el, content) {
    console.log('3: RENDERER RENDER')
    if (!this.checkIfDomEl(el)) throw new Error(`请传入有效的DOM元素，当前接收：${el}, ${typeof el} `);
 
    const finalContent = content || this.noResultContent;
    
    el.appendChild(finalContent);
  }
 
}
--------
class Mailbox extends Renderer {
  rootEl;
 
  constructor(selector) {
    super();
    this.rootEl = document.querySelector(selector);
  }
 
  renderTitle(content) {
    if (!content) return null;
 
    const titleEl = super.createElementWithTextInside('h3', 'mailbox-title', content)
 
    super.render(this.rootEl, titleEl);
 
  }
 
  render() {
    console.log('2: MAILBOX RENDER')
    super.render(this.rootEl);
  }
}
--------
class MailboxInbox extends Mailbox {
 
  title = "Inbox"
 
  constructor(params) {
   const { selector } = params;
   super(selector); 
  }
 
  renderTitle() {
    super.renderTitle(this.title);
  }
 
  render() {
    console.log('1: INBOX RENDER')
    super.render();
  }
}
--------
const inbox = new MailboxInbox({selector: '#container'}); 
inbox.renderTitle()

控制台输出：

1: INBOX RENDER
2: MAILBOX RENDER
3: RENDERER RENDER

更新说明：
我原本希望基类的render方法能接受参数(el,content)（content为可选），子类则在自己的.render()方法中重写，使用预定义的el和content等。但在Renderer内部调用render时，会遍历整个继承链，导致参数丢失——因为MailboxInbox的render方法当前不接受参数。目前想到两个方向：要么让所有子类的render方法都接受参数并传递，要么在Renderer中定义一个专用的baseRender方法直接调用。

针对你的需求，有两种直接可行的方案：

方案一：定义基类专用的底层渲染方法 #

在Renderer类中新增一个仅用于底层DOM操作的方法（比如baseRender），这个方法不被子类重写，所有需要直接调用基类渲染逻辑的地方都用这个方法替代render。

修改后的Renderer类关键部分：

class Renderer {
  // ... 其他方法保持不变

  /**
   * 底层DOM渲染逻辑，不被子类重写
   */
  baseRender(el, content) {
    console.log('BASE RENDERER RENDER')
    if (!this.checkIfDomEl(el)) throw new Error(`请传入有效的DOM元素，当前接收：${el}, ${typeof el} `);
 
    const finalContent = content || this.noResultContent;
    
    el.appendChild(finalContent);
  }

  // 原render方法保持，供子类重写
  render(el, content) {
    this.baseRender(el, content);
  }

  createElementWithTextInside(tag, className, content) {
    const el = this.createElement(tag, className);
    const text = this.createTextNode(content);
    // 直接调用baseRender，跳过继承链
    this.baseRender(el, text);
    return el;
  }
}

这样无论是Renderer内部还是子类需要调用基类核心渲染逻辑时，都可以直接用baseRender，而子类的render方法依然可以自由重写，不会影响底层逻辑。

方案二：强制调用基类原型上的render方法 #

如果不想新增方法，可以直接通过Renderer.prototype.render.call(this, el, content)的方式，强制调用基类原型上的render方法，并绑定当前实例的上下文。

修改Renderer的createElementWithTextInside方法：

createElementWithTextInside(tag, className, content) {
  const el = this.createElement(tag, className);
  const text = this.createTextNode(content);
  // 直接调用Renderer原型上的render方法，绑定当前this
  Renderer.prototype.render.call(this, el, text);
  return el;
}

这种方式不需要修改子类，直接绕过原型链查找，强制使用基类的render实现，同时保留当前实例的上下文（比如this.checkIfDomEl、this.noResultContent依然能正常访问）。

补充建议 #

如果选择方案一，建议在基类中明确区分“可重写的入口方法”和“不可重写的底层方法”，这样能避免子类误改核心逻辑；如果是临时场景，方案二更灵活，不需要调整类结构。

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