PowerShell v2中哈希表成员能否实现静态类型？

Great question! Let's break this down clearly—first, the core issue here is that PowerShell's default hashtables (created with @{}) are instances of System.Collections.Hashtable, which stores all keys and values as object types by design. This means they're inherently dynamic, so there's no built-in way to enforce static types for individual members directly.

When you do $hash = @{ int = [int]$null }, you're just casting the initial value to int, but the hashtable itself doesn't track or enforce that type for future assignments. Since the underlying storage is object, assigning a string later ($hash.int = 'string') is still valid because strings can be boxed into object.

Let's look at your options, tailored to your PowerShell v2 requirement:

1. Use Generic Dictionaries (v2-Compatible) #

If your use case allows for a single value type across all entries, System.Collections.Generic.Dictionary is a perfect fit—it’s supported in v2 and enforces strict type checking for both keys and values. For example:

# Create a dictionary where keys are strings and values are integers
$dict = New-Object 'System.Collections.Generic.Dictionary[string, int]'
$dict['int'] = 42  # Works as expected
$dict['int'] = 'string'  # Throws an error: Cannot convert value "string" to type "System.Int32"

The catch here is that all values must match the specified type—you can’t mix int and string entries. If you need mixed types, this isn’t the right solution.

2. Wrap the Hashtable with Type-Checking Logic #

If you need a flexible hashtable with per-member type constraints, build a simple wrapper function to validate assignments before they’re stored. This keeps the hashtable’s convenience while adding type safety:

function Set-HashTypedValue {
    param(
        [Parameter(Mandatory=$true)]
        [Hashtable]$Hash,
        [Parameter(Mandatory=$true)]
        [string]$Key,
        [Parameter(Mandatory=$true)]
        [object]$Value,
        [Parameter(Mandatory=$true)]
        [Type]$ExpectedType
    )

    # Validate type (allow $null if the type supports it)
    if ($null -ne $Value -and $Value -isnot $ExpectedType) {
        throw "Value for key '$Key' must be of type $($ExpectedType.Name); got $($Value.GetType().Name) instead."
    }
    $Hash[$Key] = $Value
}

# Usage example
$hash = @{ int = [int]$null; string = [string]$null }
Set-HashTypedValue -Hash $hash -Key 'int' -Value 123 -ExpectedType [int]  # Valid
Set-HashTypedValue -Hash $hash -Key 'int' -Value 'oops' -ExpectedType [int]  # Throws error

You can even extend this to track expected types in a separate hashtable so you don’t have to pass ExpectedType every time.

3. Revisit Custom Objects (v2-Friendly) #

I get why you find custom objects less concise, but in v2 you can create them fairly cleanly with New-Object PSObject -Property. While they’re still dynamic by default, you can combine them with type-checking or define strict properties using Add-Member:

$obj = New-Object PSObject
# Add a strictly typed int property
$obj | Add-Member -MemberType NoteProperty -Name 'int' -Value [int]$null -Type [int]
# Add a strictly typed string property
$obj | Add-Member -MemberType NoteProperty -Name 'string' -Value [string]$null -Type [string]

Note that PowerShell still allows assigning mismatched types by default, but you can add validation using ValidateScript in the Add-Member call for stricter enforcement.

Final Takeaway #

The short answer is: there's no built-in way to enforce static types for individual hashtable members—that’s not what hashtables are designed for. Their strength is flexibility, not type safety. Custom objects (or generic dictionaries, or wrapped hashtables) exist specifically to fill that gap when you need type constraints.

Given your v2 requirement, the wrapper function or generic dictionary (if it fits your use case) are probably the best bets.

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