NetSuite Suitelet生成PDF文件名异常：返回scriptlet.nl而非指定PDF名

我之前也碰到过类似的NetSuite Suitelet PDF文件名异常的情况，结合实际排查经验，给你梳理几个关键的排查方向：

• 检查响应头的完整性与规范性
  这是最常见的问题根源。确保在返回PDF前，正确设置了Content-Disposition和Content-Type响应头，而且格式要符合HTTP标准。示例代码如下：

  response.setHeader({
      name: 'Content-Disposition',
      value: 'attachment; filename="your-target-filename.pdf"'
  });
  response.setHeader({
      name: 'Content-Type',
      value: 'application/pdf'
  });
  

  注意几个细节：文件名要用双引号包裹，避免特殊字符导致解析失败；Content-Type必须设为application/pdf，否则浏览器可能无法识别文件类型。如果头设置顺序错误或者参数缺失，NetSuite很可能会 fallback 到默认的scriptlet.nl文件名。

• 确认PDF返回的调用逻辑
  如果你使用response.writeFile()返回PDF，要确保isInline参数设置正确——如果是作为附件下载，isInline应该设为false，同时配合上面的响应头。另外，要排查是否在返回PDF之前有意外的输出（比如误加的log.debug内容、空白字符），这些冗余输出会干扰响应头的解析，导致浏览器无法正确识别文件名。

• 排查NetSuite版本或环境变更
  有时候NetSuite的版本升级会对响应头的处理逻辑做细微调整。比如旧版本可能允许不带双引号的文件名，但新版本要求严格遵循HTTP规范。可以尝试把文件名用双引号包裹（如上面的示例），这是更稳妥的写法。另外，检查是否切换了沙盒/生产环境，不同环境的配置差异也可能导致这类问题。

• 验证脚本部署与权限设置
  虽然直接影响文件名的概率较低，但还是要确认脚本部署的配置有没有被修改——比如“可用域”“执行上下文”的变更，可能间接导致响应处理异常。如果是先生成PDF文件再返回，还要确保脚本有足够的权限读取该文件（比如文件柜的访问权限）。

• 检查PDF生成逻辑的隐性错误
  如果是通过render.xmlToPdf()或其他API生成PDF，先确认生成的PDF本身是否正常。可以临时把生成的PDF保存到文件柜，手动打开验证是否完整。如果生成过程中有隐性报错，NetSuite可能会返回默认的脚本页面（即scriptlet.nl）而非预期的PDF文件。

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