这绝对是一个巧妙的把戏。但是，公开指针仍然可以直接访问可用数据，因此，它只为您提供了额外的灵活性，以便将来进行更改。此外，
Go约定不要求您始终将抽象放在数据属性前面 。
综合考虑这些因素，对于给定的用例，我倾向于一个极端或另一极端：要么a）仅仅设置一个公共属性（在适用时使用嵌入），然后传递具体类型，要么b）如果看起来像暴露数据那样稍后造成麻烦，请公开获取器/设置器以获得更可靠的抽象。
您将在每个属性的基础上进行权衡。例如，如果某些数据是特定于实现的，或者由于其他原因您希望更改表示形式，则您可能不想直接公开该属性，而其他数据属性可能足够稳定，因此将其公开是绝对的胜利。
将属性隐藏在getter和setter的后面，可以为以后提供向后兼容的更改提供更多的灵活性。假设您某天想更改
Person为不仅存储单个“名称”字段，还存储第一/中间/最后/前缀；如果您有方法
Name()string和
SetName(string)，则可以
Person在添加新的更细粒度的方法的同时让界面的现有用户满意。或者，您可能希望在未保存更改的情况下将数据库支持的对象标记为“脏”。您可以在数据更新全部通过
SetFoo()方法时执行此操作。
因此：使用getters / setter方法，您可以在维护兼容API的同时更改struct字段，并在属性get /sets周围添加逻辑，因为没有人
p.Name = "bob"无需浏览代码就可以这样做。
当类型复杂（并且代码库很大）时，这种灵活性更为重要。如果您有一个
PersonCollection，则它可能在内部由
sql.Rows，一个
[]*Person，一个
[]uint数据库ID或其他ID支持。使用正确的界面，您可以节省呼叫者的烦恼，
io.Reader使网络连接和文件看起来像样。
一件事：
interfaceGo中的s具有独特的属性，您无需导入定义它的包就可以实现它。这可以帮助您避免周期性进口。如果您的接口返回一个
*Person，而不只是字符串或其他任何东西，则都
PersonProviders必须将包导入
Person定义的位置。这可能是好的，甚至是不可避免的；这只是要知道的结果。
但是同样， Go社区没有严格的约定禁止在类型的公共API中公开数据成员
。在给定情况下，将对属性的公共访问作为API的一部分使用是否合理是您的判断，而不是阻止 任何 公开，因为这可能会使以后的复杂化或阻止实现更改，是否合理。
因此，例如，stdlib做类似的事情，让您
http.Server使用配置初始化a
并承诺可以使用零
bytes.Buffer。这样做自己的事很好，而且，实际上，如果更具体的，数据公开的版本似乎可行，那么我不建议您先将东西抽象掉。这只是要注意权衡。
