这是一个有趣的想法！
你知道Go支持的所有操作系统是否对这个问题有一个明确的答案吗？通过具体说明它在每个操作系统上应该如何表现，或者至少在你熟悉的操作系统子集中的表现，可能会有助于扩展这个提案。
os.UserConfigDir 今天的局限性在于它只返回基本目录是什么，而对于该目录内部预期的命名方案却一无所知。例如，我认为在Windows上，习惯于创建两级子目录，如 Vendor Name\Application Name ,然后在该目录下创建文件，而在macOS上，习惯于使用反向DNS形状的名称，如 org.golang 或 com.example.appname 。我预计 SysConfigDir 提议的限制也类似，但如果它对 os.UserConfigDir 没有影响，那么也许这并不重要。🤷‍♂️

用户配置目录提案用于跨引用 #29960
我也喜欢这个想法，对我来说，这听起来就像是这种功能性需求的适当程度的间接性，如果我们开始对用户如何使用它施加太多限制，我们可能会使整体上它的实用性降低。
也许沿着这些线路，对于系统配置目录会起作用：

// SysConfigDir returns the default root directory to use for system-wide
// configuration data. Applications should use this directory for storing
// configuration files that are accessible system-wide.
//
// On Unix systems, it returns /etc.
// On Darwin, it returns /Library/Preferences.
// On Windows, it returns %ProgramData%.
// On Plan 9, it returns /lib.
//
// If the location cannot be determined, it will return an error.
func SysConfigDir() (string, error) {
	var dir string
	switch runtime.GOOS {
	case "windows":
		dir = os.Getenv("ProgramData")
		if dir == "" {
			return "", errors.New("%ProgramData% is not defined")
		}
	case "darwin":
		dir = "/Library/Preferences"
	case "plan9":
		dir = "/lib"
	default: // Unix
		dir = "/etc"
	}
	return dir, nil
}

@mauri870 我也考虑过在Windows中使用ProgramData环境变量，但是它的文档建议不要这样做：https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-folderlocations-programdata

你可以尝试在Windows中使用CSIDL_COMMON_APPDATA常量，需要安装golang.org/x/sys/windows包：

package main

import (
    "fmt"
    "golang.org/x/sys/windows"
)

func main() {
    path, err := windows.KnownFolderPath(windows.FOLDERID_ProgramData, 0)
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(path)
}

但是，在这里使用外部包可能会使事情变得更加复杂。

文件夹ID_ProgramData的描述非常符合我们的需求，不确定是否需要在操作系统中引入x/sys/windows,我认为我们需要一个更轻量级的解决方案。
无论如何，似乎每个平台都有一个专门为其准备的文件夹，我们只需要弄清楚如何访问它。
让我们等待看看大家对这个提案有什么看法。
/cc @ianlancetaylor@robpike