PowerShell模块化架构需遵循标准化结构、作用域控制与自动加载机制。模块根目录名须与.psm1/.psd1文件名一致，存放于$env:PSModulePath路径下；必须包含.psd1清单文件以支持版本管理与发布；函数须符合CmdletBinding、批准动词及类型验证规范；测试用Pester，发布前用PSScriptAnalyzer检查并推送至PowerShell Gallery。
powershell 模块化架构不是把脚本拆成几个文件就完事，而是通过标准化结构、作用域控制和自动加载机制，让运维工具真正具备可维护性、可复用性和可发布性。核心在于把功能封装进有边界、有元数据、能被系统识别的模块单元。
模块结构必须规范，否则系统找不到你
PowerShell 依赖目录名、文件名和路径三者严格一致来自动发现模块。不满足条件，Get-Module -ListAvailable 就不会列出它，Import-Module 也得手动指定完整路径。
- 模块根目录名必须与 .psm1 和 .psd1 文件名完全相同（如 MyTool 目录下必须是 MyTool.psm1）
- 模块必须放在 $env:PSModulePath 中的某个路径里（常见位置：$HOME\Documents\PowerShell\Modules 或 $HOME\Documents\WindowsPowerShell\Modules）
- 推荐使用 Public/ 存公开函数（用户直接调用），Private/ 存内部辅助函数（避免污染全局命名空间）
清单文件（.psd1）不是可选，而是模块的身份证
没有 .psd1 文件，PowerShell 就无法识别版本、作者、依赖或导出哪些函数。它不只是“描述”，而是模块参与 PowerShellGet 发布、版本管理、依赖解析的前提。
- 用 New-ModuleManifest 创建初始清单，关键参数包括 RootModule（指向 .psm1）、FunctionsToExport（明确声明哪些函数对外可见）、PowerShellVersion（限定兼容环境）
- 不要手动编辑 .psd1 的哈希表结构，容易出语法错误；用 Update-ModuleManifest 安全更新
- 清单中填好 Description 和 Tags，方便别人在 PowerShell Gallery 搜索时发现你的模块
函数设计要遵循 PowerShell 语言契约
模块的价值最终由其中的函数体现。高级函数不是写完就能用，必须符合 PowerShell 的语义规范，才能被其他管理员理解、信任和复用。
- 动词必须来自 Get-Verb 返回的批准列表（如 Get-、Set-、Invoke-），名词部分加唯一前缀（如 Get-MyOrgDiskUsage）
- 每个函数开头加 [CmdletBinding()]，启用高级参数支持（如 -Verbose、-WhatIf）
- 参数必须带类型声明和验证属性（如 [ValidateScript({Test-Path $_})]），错误处理统一用 try/catch + Write-Error 或 Write-Warning
测试和发布是模块走向生产的关键一步
一个只在自己机器上跑通的模块，离真正可用还有距离。模块化运维工具要经得起验证，也要便于他人获取。
- 把单元测试放进 Tests/ 目录，用 Pester 框架编写，覆盖主要分支和异常路径
- 发布前用 PSScriptAnalyzer 扫描代码，修复所有 Error 级别问题，处理重要 Warning
- 用 Save-Module 先存到本地验证，再用 Publish-Module 推送到 PowerShell Gallery，附带清晰的 README 和使用示例
