我正在設置一個客戶端，該客戶端對服務器進行RPC調用，該客戶端在概念上使用a或a進行響應，但實際上只是單個基本結構類型。a 和 a 都有一個字段，但需要由客戶端進行區分以進行下游處理。我想在 Go 中定義此結構的一種方式是：GetTaskMapTaskReduceTaskMapTaskReduceTaskfilenametype Task struct {  filename string  taskType string}其中要么是 或 。然后，客戶端可以使用此結構類型上的一些幫助程序函數來確定它接收的類型：taskType"map""reduce"Taskfunc (t *Task) isMapTask() bool {  t.taskType == "map"}func (t *Task) isReduceTask() bool {  t.taskType == "reduce"}這將工作得相當好，并在結構類型中隱藏復雜性/實現細節。我看到的一個問題是，對于可以具有的值沒有約束 - 因此客戶端可以接收既不是Map也不是Reduce類型的。我擔心的另一個問題是，我不確定這種結構是否存在一些我沒有想到的陷阱。taskTypeTask我的問題是，上述結構對于圍棋來說是否合理和/或慣用語？順便說一句，我來自Ruby的OO背景，我可以想象Ruby偽代碼中的以下結構：class BaseTaskclass MapTask < BaseTaskclass ReduceTask < BaseTask當然，這并不能很好地映射到Go。