在表单开发中，placeholder属性在IE9及以下版本中无法原生显示，这会让输入框失去引导性提示。解决思路通常是先进行能力检测，确认浏览器是否支持placeholder，如果不支持再加载jQuery Placeholder插件或自行实现模拟逻辑。

placeholder兼容性问题的本质

HTML5为<input>和<textarea>元素新增了placeholder属性，用来在输入框为空时显示灰色提示文字。现代浏览器会自动处理焦点变化、文字颜色和表单提交行为。但在IE9及以下版本中，浏览器无法识别这个属性，输入框既不会显示提示文字，也不会在DOM中暴露相应的样式状态。开发者需要自行检测当前环境是否支持该属性，才能决定是否启用模拟方案。

能力检测的代码非常简单，可以创建一个临时的<input>元素，判断placeholder是否存在于该元素对象上。脚本如下：

function supportsPlaceholder() {
  var input = document.createElement('input');
  return 'placeholder' in input;
}
if (!supportsPlaceholder()) {
  // 在此处加载jQuery Placeholder插件或执行自定义模拟逻辑
}

这里的判断使用了in运算符，不会触发属性值读取，性能开销极小。如果返回false，就说明浏览器属于旧版IE或不支持placeholder的环境。此时所有依赖原生提示的交互都需要通过脚本补全，包括聚焦清空、失焦恢复、样式切换以及表单提交前的数据清理。理解这一点是使用插件和自定义polyfill的基础。

实际项目中为了避免重复造轮子，直接引入jQuery Placeholder插件是常见做法。插件内部同样基于能力检测，只在需要时执行模拟，不会影响现代浏览器的原生行为。不过在使用插件前，仍需理解模拟机制的边界，比如密码框如何处理、动态添加元素如何绑定。

使用jQuery Placeholder插件快速实现

jQuery Placeholder插件的使用门槛较低，通常只需引入jQuery和插件脚本，然后在DOM加载完成后对带有placeholder属性的表单元素调用插件方法。整个过程不需要修改HTML结构，也不需要额外编写样式，插件会为模拟提示文字添加默认样式类。

<script src="jquery.min.js"></script>
<script src="jquery.placeholder.js"></script>
<script>
$(function () {
  $('input[placeholder], textarea[placeholder]').placeholder();
});
</script>

在上面的示例中，选择器input[placeholder]用于匹配所有设置了placeholder属性的输入框，textarea[placeholder]则覆盖多行文本域。插件初始化时会自动检测当前浏览器是否支持原生placeholder。如果支持，插件通常不会做任何处理；如果不支持，它会读取placeholder属性值，并将其作为模拟提示写入输入框。

使用插件时需要注意两个细节。第一，初始化时机要放在DOM ready之后，否则无法获取到页面中的表单元素。第二，如果页面通过AJAX动态加载新表单，新添加的元素不会自动获得模拟能力，需要在AJAX回调中再次调用$('input[placeholder], textarea[placeholder]').placeholder()。此外，如果项目使用了requireJS等模块加载器，还需要确认插件是否支持模块化导出。

插件的默认样式类通常为placeholder，可以通过CSS定义提示文字的灰色效果。例如：

.placeholder {
  color: #999;
}

如果插件没有自动处理表单提交场景，模拟提示文字可能会被当作真实数据提交到后端。这种情况需要在提交事件中清理输入值，具体排查与处理会在后面小节展开。

不依赖插件的自定义模拟方案

如果项目对插件依赖有控制要求，或者只需要覆盖少量表单，完全可以用一段简短的jQuery代码实现placeholder模拟。核心思路是在不支持原生属性时，把placeholder的值写入输入框并添加自定义类，同时在聚焦和失焦事件中切换提示状态。提交表单前，再把仍处于提示状态的输入框置空，避免把提示文字提交给服务器。

(function ($) {
  $.fn.placeholderPolyfill = function () {
    if ('placeholder' in document.createElement('input')) {
      return this;
    }
    return this.each(function () {
      var $this = $(this);
      var text = $this.attr('placeholder');
      if ($this.val() === '') {
        $this.val(text).addClass('placeholder');
      }
      $this.on('focus.placeholder', function () {
        if ($this.val() === text) {
          if ($this.hasClass('placeholder')) {
            $this.val('').removeClass('placeholder');
          }
        }
      });
      $this.on('blur.placeholder', function () {
        if ($this.val() === '') {
          $this.val(text).addClass('placeholder');
        }
      });
      $this.closest('form').on('submit.placeholder', function () {
        if ($this.val() === text) {
          if ($this.hasClass('placeholder')) {
            $this.val('');
          }
        }
      });
    });
  };
})(jQuery);
$(function () {
  $('input[placeholder], textarea[placeholder]').placeholderPolyfill();
});

这段代码先检测原生支持，如果支持则直接返回当前jQuery对象，不执行任何模拟逻辑。对于不支持的环境，遍历每个匹配元素，读取placeholder属性并写入输入值。聚焦时如果当前值刚好等于提示文字且带有placeholder类，就清空输入并移除灰色样式；失焦时如果输入为空，则恢复提示。表单提交时也会检查并清理，防止提示文字被误提交。

这种自定义实现的优点是逻辑透明、体积小，适合对插件依赖敏感的场景。缺点是需要自己处理密码框、动态元素和复杂交互。比如type为password的输入框无法直接显示模拟文字，因为浏览器会将内容显示为掩码。这时可以使用临时切换type属性的方式，或者额外覆盖一个只读文本层来展示提示。

密码框与动态元素的特殊处理

密码框是placeholder模拟中最容易出错的场景。如果直接把提示文字写入value，在type为password的输入框中用户看到的是圆点而不是文字，完全违背提示初衷。比较常见的做法是先记录原始type值，再将type属性修改为text，显示提示文字。当用户聚焦或开始输入时，再把type恢复为password。这样用户未输入时看到的是普通提示，开始输入后输入内容会被掩码保护。

function showPlaceholder(input) {
  var $input = $(input);
  if ($input.attr('type') === 'password') {
    $input.data('placeholderType', 'password');
    $input.attr('type', 'text');
  }
  $input.val($input.attr('placeholder'));
  $input.addClass('placeholder');
}
function hidePlaceholder(input) {
  var $input = $(input);
  if ($input.data('placeholderType') === 'password') {
    $input.attr('type', 'password');
    $input.removeData('placeholderType');
  }
  $input.val('');
  $input.removeClass('placeholder');
}

需要注意，旧版IE对运行中修改input的type属性支持并不一致，部分版本会抛出异常。更稳妥的方式是在初始化时把密码框包装一个容器，在密码框上层定位一个透明或半透明的文本节点显示提示。这种方案DOM结构稍复杂，但不会触碰type属性，兼容性更好。对于大多数表单来说，如果密码框数量少，也可以直接使用独立的label或文字说明代替placeholder提示。

动态元素同样是个容易遗漏的点。页面通过AJAX或模板引擎插入新表单后，这些元素不会自动被插件或自定义脚本处理。正确的做法是提取初始化函数，在AJAX成功回调或DOM更新后再次调用。如果是单页应用，还可以使用事件委托，但placeholder模拟依赖输入框自身的焦点和失焦事件，委托方式并不能完全替代重新绑定，因此更推荐在每次插入表单后手动初始化。

常见问题与注意事项

无论是使用插件还是自定义polyfill，都需要在表单提交前清理模拟提示。许多表单在用户不填写字段时直接提交，而输入框中显示的提示文字恰好与placeholder内容相同，后端很容易把这些提示误认为真实数据。上面的自定义代码已经在submit事件中处理了这一情况，但使用第三方插件时必须查看文档确认是否包含提交清理。如果插件未提供该能力，可以在全局提交事件中统一遍历表单元素，判断带placeholder类的输入框并置空。

另一个常见问题是样式冲突。模拟提示文字在聚焦前后需要明显区分，否则用户可能分不清当前是提示还是已输入内容。建议在CSS中为placeholder类定义浅灰色，并与正常输入内容保持一定差异。部分插件还支持自定义类名，初始化时传入参数即可。例如：

$('input[placeholder], textarea[placeholder]').placeholder({
  className: 'input-placeholder'
});

能力检测也不应该被跳过。现代浏览器原生支持placeholder时，如果再执行模拟逻辑，会导致输入值被反复覆盖、焦点行为异常、密码框type切换出错等问题。因此所有插件和自定义方案都会在入口处先进行'placeholder' in document.createElement('input')判断，这一点应当在代码评审中作为基本规范。

最后需要关注的是性能。虽然placeholder模拟逻辑本身并不复杂，但如果页面包含大量输入框，初始化时应避免为每个元素单独绑定多个事件。可以使用事件委托将focus和blur绑定到父容器，或使用命名空间统一解绑，减少内存占用。对于动态表单和高频更新的页面，建议将模拟逻辑封装为可复用函数，避免重复绑定导致事件堆叠。