Office 文档不是普通的零字节文本。一个扩展名叫 .docx 的空文件，并不具备合法的 Office 包结构，直接交给 Word 往往会提示损坏。为此，密域在应用资源中准备了 .doc、.docx、.xls、.xlsx、.ppt、.pptx 的空白模板。

用户在“新建文件”中输入带扩展名的名称后，主进程读取对应模板，再通过虚拟文件系统写入容器。在正常安装资源完整、模板读取成功的路径中，创建的是可由办公软件识别的空白文档，而不是只改了后缀的空壳。该能力依赖随应用提供的模板资源；模板缺失或读取失败时，当前实现不能保证生成结果仍是有效的 Office 文档。

新建时，系统会检查名称是否为空、是否含有系统不允许的特殊字符、单级名称是否过长，以及完整容器路径是否超出限制。没有写扩展名时默认补为 .txt；Office 和内置文本类型之外的后缀则会被拒绝。提前发现问题，比在编辑数小时后才因为路径不兼容而无法保存更友好。

新文件出现在当前目录后，双击即可交给相应外部应用。密域负责建立外部编辑会话并在容器挂载中提供文件访问，用户则继续在 Word、Excel 或 PowerPoint 中完成内容。macOS 上遇到明确的 Office 兼容问题时，系统可能改用受管临时副本，并在会话结束后同步回容器和清理。对于 Markdown、代码和其他支持的文本类型，可以直接在内置 Monaco 编辑器中打开；拥有写入授权时还可以保存回容器。

从“先在桌面创建源文件，再导入容器”，变成“直接在容器中创建正式文件”，看似只是一个新建菜单的变化，实际减少了一段容易被忽略的手工明文链路。外部 Office 通常通过挂载别名读写；macOS 的明确兼容场景仍可能产生会被同步和清理的受管工作副本。因此，这项能力的准确价值是降低明文散落风险，而不是承诺任何平台、任何编辑器都绝不会在容器外产生工作副本。