Ruby中@前缀实例变量的用法解析（含类外使用场景）

Great question! Let’s unpack what’s going on with those @-prefixed variables in your Ruby code snippet—they’re not as odd as they might seem at first.

What Are Those @ Variables Outside a Class? #

In Ruby, when you write code outside of any class, module, or method definition (the "top-level scope"), you’re actually executing code in the context of a special object called main. This main is an instance of the Object class, and any @-prefixed variable you define here becomes an instance variable of the main object.

In your code:

require "mysql"
@db_host = "localhost"
@db_user = "root"
@db_pass = "root"
@db_name = "your_db_name"
client = Mysql::Client.new(:host => @db_host, :username => @db_user, :password => @db_pass, :database => @db_name)
@cdr_result = client.query("SELECT * from your_db_table_name")

All the @db_* variables and @cdr_result belong to the main object. They work exactly like instance variables inside a class—they’re tied to their owning object (main here) and persist for the lifetime of the script.

How Is This Different From Local Variables? #

If you’d defined these without the @ (e.g., db_host = "localhost"), they’d be local variables. The key differences are:

• Scope: Local variables are only accessible within the immediate code block/method they’re defined in. main’s instance variables, however, are accessible anywhere in the top-level scope, even inside methods defined at the top level (since those methods are added to the Object class, and when called from main, self refers to main). For example:

  @db_host = "localhost"
  
  def print_host
    puts @db_host # Outputs "localhost"—this works because self is main
  end
  
  print_host
  

• Persistence: Local variables are garbage-collected once their scope ends, but main’s instance variables stick around until the script finishes running.

Pros and Cons of This Approach #

• Pros: It’s quick and straightforward for small scripts, one-off tasks, or simple database connections like your example. You don’t need to set up extra classes/modules to hold configuration.
• Cons: For larger projects, this approach can get messy. You’re polluting the main object’s namespace, which increases the risk of naming conflicts. A better practice is to encapsulate configuration using a module or class, which makes your code more organized and maintainable:

Example with a Module (for constant config) #

require "mysql"

module DBConfig
  HOST = "localhost"
  USER = "root"
  PASS = "root"
  NAME = "your_db_name"
end

client = Mysql::Client.new(
  host: DBConfig::HOST,
  username: DBConfig::USER,
  password: DBConfig::PASS,
  database: DBConfig::NAME
)
cdr_result = client.query("SELECT * from your_db_table_name")

Example with a Class (for dynamic config) #

require "mysql"

class DBConfig
  attr_reader :host, :user, :pass, :name

  def initialize(host: "localhost", user: "root", pass: "root", name: "your_db_name")
    @host = host
    @user = user
    @pass = pass
    @name = name
  end
end

config = DBConfig.new
client = Mysql::Client.new(
  host: config.host,
  username: config.user,
  password: config.pass,
  database: config.name
)
cdr_result = client.query("SELECT * from your_db_table_name")

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